microsoftgraph / microsoftgraph/msgraph-sdk-java

Calling toPatchInformation prior to calling patch causes patch to silently fail

Aperta
#2,295 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

status:waiting-for-triage type:bug
Lingua principale
Java
Stelle
444
Fork
154
Merge medio
18h 28m
PR unite (30g)
4

Descrizione

Describe the bug

When calling a patch operation on an Application request, calling toPatchInformation causes the .patch(app) to not work. If true, then this probably needs either a doc update or a fix.

This does not work, but no error is thrown and the logs are clean it seems:

// DOES NOT WORK
val trequest = graphClient.applications().byApplicationId(oid)
val emptyApp = Application()
emptyApp.setNotes(s"Updated via code. ${java.time.ZonedDateTime.now()}")
trequest.toPatchRequestInformation(emptyApp)
trequest.patch(emptyApp)

but this works and the application registration is changed

// WORKS
val trequest = graphClient.applications().byApplicationId(oid)
val emptyApp = Application()
emptyApp.setNotes(s"Updated via code. ${java.time.ZonedDateTime.now()}")
//trequest.toPatchRequestInformation(emptyApp)
trequest.patch(emptyApp)

This may be related to something not idempotent and there is some hidden state somewhere.

OTEL logging suggest that the only difference in calling is that the following is called twice when including the toPatchRequestInformation prior to patch. patch also calls toPatchRequestInformation as well. However,
it looks like creating RequestInformation is idempotent...hmm...

// this is the only difference in the trace which is expected since setContentFromParsable is called when toPatchRequestInformation is called.
[otel.javaagent 2025-02-09 16:38:49:625 -0500] [main] INFO io.opentelemetry.exporter.logging.LoggingSpanExporter - 'setContentFromParsable' : ace455a22586ba518b85e4a1b307630d b731da65e1939a46 INTERNAL [tracer: com.microsoft.kiota:] AttributesMap{data={thread.id=1, com.microsoft.kiota.request.type=com.microsoft.graph.models.Application, thread.name=main}, capacity=128, totalAddedValues=3}
[otel.javaagent 2025-02-09 16:38:49:625 -0500] [main] INFO io.opentelemetry.exporter.logging.LoggingSpanExporter - 'setContentFromParsable' : 9e931b04f0305f0ef5df1bb3a8b59f78 30a5455e58f3fb17 INTERNAL [tracer: com.microsoft.kiota:] AttributesMap{data={thread.id=1, com.microsoft.kiota.request.type=com.microsoft.graph.models.Application, thread.name=main}, capacity=128, totalAddedValues=3}
Expected behavior

The patch works even if toPatchRequestInformation is called prior to calling patch.

How to reproduce
SDK Version

6.x, latest

Latest version known to work for scenario above?

No response

Known Workarounds

None

Debug output
Click to expand log ```
</details>


### Configuration

_No response_

### Other information

_No response_

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Direzione di ricerca

Inizia dai punti di ingresso delle richieste di Application toPatchRequestInformation e patch, quindi confronta le loro chiamate ripetute a setContentFromParsable e qualsiasi stato della richiesta condiviso. Riproduci le due sequenze dell’issue e aggiungi un test di regressione che dimostri che chiamare prima toPatchRequestInformation non impedisce a patch di aggiornare l’Application.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
java
Ambito
api
Tipo di issue
Bug
Difficoltà
4/5
Tempo stimato
3-5 giorni
Stato di attività
Ferma
Chiarezza
Abbastanza chiara
Idoneità per principianti
35/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.