Vihren Atlas

api.go ×8

Code frontier

unlabeled · c_54c173a716b1

58 tests · 6689 LOC · 204 files · introduces 0 tests · 39 LOC · 1 file

Introduces — evidence that enters the hierarchy at this concept

Code
8 ranges39 lines · 1 files
Tests
0 tests

Contains — complete concept membership

All code (extent)
1391 ranges6689 lines · 204 files · Browse complete extent
All tests (intent)
58 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.

1 file ranked by introduced lines: 39 introduced LOC across 8 ranges. Expand a file to inspect source; the > gutter marks introduced lines.

go.temporal.io/server/service/history/api/respondworkflowtaskcompleted/api.go 39 introduced LOC · 8 ranges

Open complete file

286 // `commands` is the effective list of commands to execute including ones from
287 // paginated requests. `request.Commands` is left unchanged.
288 > commands := request.Commands api.go
289 > if len(mergedCommands) > 0 {
290 commands = append(mergedCommands, request.Commands...)
291 }
292
293 > limits := historyi.WorkflowTaskCompletionLimits{ api.go
294 > MaxResetPoints: handler.config.MaxAutoResetPoints(nsName),
295 > MaxSearchAttributeValueSize: handler.config.SearchAttributesSizeOfValueLimit(nsName),
296 > }
297 > // TODO: this metric is inaccurate, it should only be emitted if a new binary checksum (or build ID) is added in this completion.
298 > if ms.GetExecutionInfo().AutoResetPoints != nil && limits.MaxResetPoints == len(ms.GetExecutionInfo().AutoResetPoints.Points) {
299 metrics.AutoResetPointsLimitExceededCounter.With(handler.metricsHandler).Record(
300 1,
302 }
303
304 > var wtHeartbeatTimedOut bool api.go
305 > var completedEvent *historypb.HistoryEvent
306 >
307 > // SDKs set ForceCreateNewWorkflowTask flag to true when they are doing WT heartbeats.
308 > // In a mean time, there might be pending commands and messages on the worker side.
309 > // If those commands/messages are sent on the heartbeat WT it means that WF is making progress.
310 > // WT heartbeat timeout is applicable only when WF doesn't make any progress and does heartbeats only.
311 > checkWTHeartbeatTimeout := request.GetForceCreateNewWorkflowTask() && len(commands) == 0 && len(request.Messages) == 0
312 >
313 > if checkWTHeartbeatTimeout {
314 // WorkflowTaskHeartbeatTimeout is a total duration for which workflow is allowed to send continuous heartbeats.
315 // Default is 30 minutes.
336 }
337 // WT wasn't timed out (due to too many heartbeats), therefore WTCompleted event should be created.
338 > if !wtHeartbeatTimedOut { api.go
339 completedEvent, err = ms.AddWorkflowTaskCompletedEvent(currentWorkflowTask, request, limits)
340 if err != nil {
345 // See workflowTaskStateMachine.skipWorkflowTaskCompletedEvent for more details.
346
347 > if request.StickyAttributes == nil || request.StickyAttributes.WorkerTaskQueue == nil { api.go
348 metrics.CompleteWorkflowTaskWithStickyDisabledCounter.With(handler.metricsHandler).Record(
349 1,
350 metrics.OperationTag(metrics.HistoryRespondWorkflowTaskCompletedScope))
351 ms.ClearStickyTaskQueue()
352 > } else { api.go
353 metrics.CompleteWorkflowTaskWithStickyEnabledCounter.With(handler.metricsHandler).Record(
354 1,
365 }
366
367 > var ( api.go
368 > wtFailedCause *workflowTaskFailedCause
369 > activityNotStartedCancelled bool
370 > newMutableState historyi.MutableState
371 > responseMutations []workflowTaskResponseMutation
372 > )
373 > updateRegistry := weContext.UpdateRegistry(ctx)
374 > // hasBufferedEventsOrMessages indicates if there are any buffered events
375 > // or admitted updates which should generate a new workflow task.
376 >
377 > // TODO: HasOutgoingMessages call (=check for admitted updates) is comment out
378 > // because non-durable admitted updates can't block WF from closing,
379 > // because everytime WFT is failing, WF context is cleared together with update registry
380 > // and admitted updates are lost. Uncomment this check when durable admitted is implemented
381 > // or updates stay in the registry after WFT is failed.
382 > hasBufferedEventsOrMessages := ms.HasBufferedEvents() // || updateRegistry.HasOutgoingMessages(false)
383 > if paginationOverflow {
384 // Per-workflow completion buffer overflowed: terminate the workflow
385 wtFailedCause = newWorkflowTaskFailedCause(
388 "workflow task completion buffer size exceeds the per-workflow limit"),
389 true)
390 > } else if err := namespaceEntry.VerifyBinaryChecksum(request.GetBinaryChecksum()); err != nil { //nolint:staticcheck // SA1019 deprecated stamp will clean up later api.go
391 wtFailedCause = newWorkflowTaskFailedCause(
392 enumspb.WORKFLOW_TASK_FAILED_CAUSE_BAD_BINARY,

Direct hierarchy

Parents

Children