update.go ×4

Frontier kind: Code frontier

unlabeled · c_0fbac7da51c5

27 tests · 2257 LOC · 112 files · introduces 0 tests · 30 LOC · 2 files

Introduces — evidence that enters the hierarchy at this concept

Code
5 ranges30 lines · 2 files
Tests
0 tests

Contains — complete concept membership

All code (extent)
348 ranges2257 lines · 112 files · Browse complete extent
All tests (intent)
27 testsBrowse complete intent

Neighbourhood graph

The orange circle is the focus. Violet and green circles are every ancestor and descendant, broader and narrower, at any distance; blue squares and pink diamonds are the introduced files and exact introduced tests of every visible concept, not only the focus's. Arrows point from broader to narrower concepts and bridge only concepts omitted from this view. Undirected links show source or test introduction. Concept and file size follows LOC; exact test nodes use test-count units.

Introduced files, introduced tests, and structurally relevant concept specialization

In the embedded map, ordinary wheel input scrolls the page; use the visible controls to zoom and drag to pan. Open the full-screen map for canvas navigation: wheel pans, Ctrl/Command plus wheel zooms, and arrow keys pan when this region is focused. On touch screens, open the full-screen map to pan or pinch. If JavaScript or WebGL is unavailable, use the native relationship evidence on this page.

Graph controls are ready.

Interactive rendering requires JavaScript and WebGL. Use the native relationship evidence on this page while the interactive map is unavailable.

Native relationship evidence

Every exact file and test below is linked only from the concept that introduces it.

Introduced tests

Every collected test enters the hierarchy at exactly one concept.

No tests are introduced at this concept. Its intent tests are introduced by other concepts.

Introduced code

Every collected source range enters the hierarchy at exactly one concept.

2 files ranked by introduced lines: 30 introduced LOC across 5 ranges. Expand a file to inspect source; the > gutter marks introduced lines.

go.temporal.io/server/service/history/workflow/update/update.go 27 introduced LOC · 4 ranges

Open complete file

464 // stateSent. The per-update callback limit (MaxCallbacksPerUpdateID) bounds the
465 // worst case.
466 > func (u *Update) persistPendingCallbacks(eventStore EventStore) error { update.go
467 > for _, pc := range u.pendingCallbacks {
468 if _, err := u.persistCallback(eventStore, pc.requestID, pc.completionCallbacks); err != nil {
469 return err
621 return err
622 }
623 > u.instrumentation.countAcceptanceMsg() update.go
624 >
625 > // If the in-registry Update lacks a request payload, this implies that there is an UpdateAdmitted event in
626 > // history. In this case, we write the UpdateAccepted event without a request payload, since the UpdateAdmitted
627 > // event has it.
628 > //
629 > // Thus, the following sequences of events are all possible, and SDK workers must handle them correctly:
630 > // UpdateAdmitted(requestPayload)
631 > // UpdateAdmitted(requestPayload)
632 > // ...
633 > // UpdateAccepted(nil)
634 > // UpdateAccepted(requestPayload)
635 > var acceptedRequest *updatepb.Request
636 > if u.request != nil {
637 acceptedRequest = &updatepb.Request{}
638 if err := u.request.UnmarshalTo(acceptedRequest); err != nil {
641 }
642
643 > event, err := eventStore.AddWorkflowExecutionUpdateAcceptedEvent( update.go
644 > u.id,
645 > u.outgoingMessageID(),
646 > acpt.AcceptedRequestSequencingEventId,
647 > acceptedRequest)
648 > if err != nil {
649 return err
650 }
651 > u.acceptedEventID = event.EventId update.go
652 >
653 > // Persist any callbacks that were buffered by AttachCallbacks while in stateSent or stateAdmitted.
654 > // See persistPendingCallbacks for why this writes one event per pending entry.
655 > if err := u.persistPendingCallbacks(eventStore); err != nil {
656 return err
657 }
go.temporal.io/server/service/history/workflow/update/util.go 3 introduced LOC · 1 range

Open complete file

34 }
35
36 > func (i *instrumentation) countAcceptanceMsg() { util.go
37 > i.oneOf(metrics.MessageTypeAcceptWorkflowExecutionUpdateCounter.Name())
38 > }
39
40 func (i *instrumentation) countRejectionMsg() {