update.pb.go ×1

Frontier kind: Code frontier

unlabeled · c_e2efff5d3da3

3 tests · 2314 LOC · 117 files · introduces 0 tests · 16 LOC · 2 files

Introduces — evidence that enters the hierarchy at this concept

Code
2 ranges16 lines · 2 files
Tests
0 tests

Contains — complete concept membership

All code (extent)
364 ranges2314 lines · 117 files · Browse complete extent
All tests (intent)
3 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: 16 introduced LOC across 2 ranges. Expand a file to inspect source; the > gutter marks introduced lines.

go.temporal.io/server/service/history/workflow/update/registry.go 14 introduced LOC · 1 range

Open complete file

189 r.store.VisitUpdates(func(updID string, updInfo *persistencespb.UpdateInfo) {
190 if updInfo.GetAdmission() != nil {
191 > // An Update entry in the Registry may have a request payload: we use this to write the payload to an registry.go
192 > // UpdateAccepted event, in the event that the Update is accepted. However, when populating the registry
193 > // from mutable state, we do not have access to Update request payloads. In this situation it is correct
194 > // to create a registry entry in state Admitted with a nil payload for the following reason: the fact
195 > // that we have encountered an UpdateInfo in stateAdmitted in mutable state implies that there is an
196 > // UpdateAdmitted event in history; and when there is an UpdateAdmitted event in history, we will not
197 > // attempt to write the request payload to the UpdateAccepted event, since the request payload is
198 > // already present in the UpdateAdmitted event.
199 > r.updates[updID] = newAdmitted(
200 > updID,
201 > nil,
202 > r.remover(updID),
203 > withInstrumentation(&r.instrumentation),
204 > )
205 } else if acc := updInfo.GetAcceptance(); acc != nil {
206 u := newAccepted(
go.temporal.io/server/api/persistence/v1/update.pb.go 2 introduced LOC · 1 range

Open complete file

267 if x != nil {
268 if x, ok := x.Value.(*UpdateInfo_Admission); ok {
269 > return x.Admission update.pb.go
270 > }
271 }
272 return nil