Add support for standalone callbacks by chrsmith · Pull Request #10192 · temporalio/temporal

chrsmith · 2026-05-07T19:16:09Z

ℹ️ This PR is a rebase and cleanup from an earlier prototype, #9805.

⚠️ This is dependent on changes in the api and api-go repos. And will need some care before merging.

What changed?

Adds support for "standalone" callbacks. Today, the CHASM Callback component is used to deliver an arbitrary payload to a URL. (e.g. when a Workflow has completed.) As part of supplying the Nexus Connector Foundations, this feature adds CRUD operations on callbacks directly. So callers can invoke StartCallbackExecution(...) and get the durability guarantees to ensure that the callback actually gets invoked.

Why?

The primary (only?) use-case for this is for completing Nexus operations. With this capability, a Handler can implement a Nexus operation outside of Temporal. And when that operation completes, simply call StartCallbackExecution(...) with the right callback URL and Token. Then the CHASM Callback machinery will attempt to deliver the result for the Nexus operation. (Rather than, say, the Nexus operation to be implemented as a Workflow that is separately polling the async or out-of-band process.)

How did you test it?

Potential risks

TBD. Will need to ask around.

stephanos · 2026-05-08T21:49:15Z

+	}
+
+	// ScheduleToCloseTimeout
+	if req.GetScheduleToCloseTimeout() == nil || req.GetScheduleToCloseTimeout().AsDuration() <= 0 {


I wonder if we want a MaxOperationScheduleToCloseTimeout? SANO has it.

I don't think we do, assuming that there is a system-wide hard cap on callbacks. (Which IIRC was like 10s.) If it is actually possible to be longer than that, then adding and maybe wiring something in would make sense.

It's important to distinguish the scope of the various timeouts. If we have/had a 10s timeout on the callback delivery attempt, that would be different from the "schedule to close" timeout which covers the entire lifecycle from creation to terminal state - including all retries.

As you can see, MaxOperationScheduleToCloseTimeout is set to zero by default. But we do set a limit in Cloud to ensure that all nexus operations eventually terminate. I think we'd want the same thing here for the same reason.

chrsmith · 2026-05-11T21:20:59Z

@stephanos thank you for the close look and detailed review, PTAL.

bergundy

I got all the way to frontend_validation.go but didn't complete reviewing that file yet.
It's a big PR, submitting my feedback so you can already take action and not be blocked until I complete reviewing the entire change.

Not blocking this PR but we should validate that temporal:// URLs have a token either via the old header format or the new structured Token field.

bergundy · 2026-05-12T00:34:28Z

Would you remove the WorkflowClosed message that is unused here please?

bergundy · 2026-05-12T00:35:18Z

+
+  // (standalone only) User-supplied business ID set when StartCallbackExecution() is
+  // called. Used to identify the callback for operations like Describe- or Terminate-.
+  string callback_id = 12;


This is available via the chasm context, no need to duplicate this information.

bergundy · 2026-05-12T00:38:30Z

+
+  // (standalone only) Schedule-to-close timeout from when StartCallbackExecution()
+  // is called to when the result gets delivered.
+  google.protobuf.Duration completion_schedule_to_close_timeout = 13;


Agree with @stephanos the callback lifetime is the completion lifetime, no need to qualify this field.

bergundy · 2026-05-12T00:38:47Z

  CALLBACK_STATUS_FAILED = 4;
  // Callback has succeeded.
  CALLBACK_STATUS_SUCCEEDED = 5;
+  // Callback was terminated by request.


Suggested change

// Callback was terminated by request.

// Callback was terminated by request. Only relevant for standalone callbacks.

bergundy · 2026-05-12T00:39:57Z

+
+  rpc DescribeCallbackExecution(DescribeCallbackExecutionRequest) returns (DescribeCallbackExecutionResponse) {
+    option (temporal.server.api.routing.v1.routing).business_id = "frontend_request.callback_id";
+    option (temporal.server.api.common.v1.api_category).category = API_CATEGORY_STANDARD;


This should be a long poll API for the purpose of this annotation (liveness detection).

hm both SANO and SAA have this as API_CATEGORY_STANDARD - did that slip through 2 reviews before?

Roey confirmed that all these should be in the long-poll category. cc #10256 for fixing up the remaining ones.

bergundy · 2026-05-12T23:34:29Z

+func (h *frontendHandler) checkFeatureEnabled(requestProto namespacer) error {
+	// Confirm CHASM is enabled.
+	targetNamespaceName := requestProto.GetNamespace()
+	if !h.config.CHASMEnabled(targetNamespaceName) || !h.config.CHASMCallbacksEnabled(targetNamespaceName) {


CHASM callbacks is a feature flag for workflow callbacks, we should name it clearly and not check this here.

bergundy · 2026-05-12T23:36:30Z

+type namespacer interface{ GetNamespace() string }
+
+// Looks up the namespace ID from the user-supplied namespace name in the request proto.
+func (h *frontendHandler) getTargetNamespace(requestProto namespacer) (namespace.ID, error) {


Please don't use the get prefix for getters in Go: https://go.dev/doc/effective_go#Getters

bergundy · 2026-05-12T23:38:06Z

+		return nil, err
+	}
+
+	resp, err := chasm.ListExecutions[*Callback, *callbackpb.CallbackExecutionListInfo](


As mentioned above, there's no need for a structured memo to implement this API.

bergundy · 2026-05-12T23:42:37Z

+// requiredField is a tuple of a required field name and its value.
+// Used instead of a map[string]string to provide deterministic
+// errors if multiple fields aren't set.
+type requiredField struct {


We've had different approaches to provide multi-error feedback from our APIs but don't have a standard in the codebase. I'm okay with introducing yet another form in this PR and have ideas for how to improve the validation process in general that I want us to tackle later on.

bergundy · 2026-05-12T23:43:04Z

+// requiredField is a tuple of a required field name and its value.
+// Used instead of a map[string]string to provide deterministic
+// errors if multiple fields aren't set.
+type requiredField struct {


nit: this is a bit more accurate for what this struct represents.

Suggested change

type requiredField struct {

type requiredStringField struct {

stephanos · 2026-05-12T23:57:41Z

+)
+
+// Test suite for the Nexus "Standalone Callbacks". Which are Nexus operations corresponding to
+// aysynchronous actions that take place outside of Temporal. (e.g. waiting for a payment to


Suggested change

// aysynchronous actions that take place outside of Temporal. (e.g. waiting for a payment to

// asynchronous actions that take place outside of Temporal. (e.g. waiting for a payment to

stephanos · 2026-05-13T00:01:30Z

+	ctx, cancel := context.WithTimeout(context.Background(), time.Second*30)
+	defer cancel()


nit: you don't really need those (anymore), technically. It's better to use testcore.NewContext() as it gives you a context with a default timeout. We're in the process of making that become s.Context() but that's not merged yet. The only benefit of doing this is using an even tighter timeout than the default. But that can backfire in CI when things take longer. So my recommendation is to remove it.

Good to know! I updated all the callsites to use ctx := env.Context(). So it's a big longer than I had with the custom timeout, but didn't wire in a lower value like the ones I had before. Since you have scared me worrying about how short durations would interact with under-powered and over-subscribed CI machines.

stephanos · 2026-05-13T00:10:23Z

+	s.NotNil(pollResp.GetOutcome(), "expected terminal outcome after timeout")
+	s.NotNil(pollResp.GetOutcome().GetFailure(), "expected failure outcome after timeout")
+	s.Contains(pollResp.GetOutcome().GetFailure().GetMessage(), "timed out")
+	s.NotNil(pollResp.GetOutcome().GetFailure().GetTimeoutFailureInfo())
+	s.Equal(enumspb.TIMEOUT_TYPE_SCHEDULE_TO_CLOSE, pollResp.GetOutcome().GetFailure().GetTimeoutFailureInfo().GetTimeoutType())


(nit) (I didn't get around to codify this in testing.md yet) I find it often useful to - where possible - try to use protorequire.ProtoEqual to assert the whole object. There's an option to ignore fields that can't be checked like UUIDs. I find it makes it much easier to see the full picture and also get a better diff.

I'll keep that in mind in the future. For this PR, I'm inclined to keep things as-is just to explicitly verify individual fields. But if I need to revisit this code in the future, I'll switch to that and just have a wantProto := ... to compare against.

stephanos · 2026-05-13T00:13:15Z

+	defer cancel()
+
+	// Short timeout so it fires quickly during the test.
+	callbackID := "timeout-test-" + uuid.NewString()


So you don't actually need the uuid.NewString() part since the testEnv you get will create a unique namespace for you. And as long as that isolation is sufficient and you don't re-use the identifier in the same test, you're good.

Good to know. I'm inclined to keep this as-is, since it looks wrong to see a hard-coded ID like that. But yes, I see how it is unnecessary.

stephanos · 2026-05-13T00:16:44Z

+	listenAddr := nexustest.AllocListenAddress()
+	nexustest.NewNexusServer(s.T(), listenAddr, h)
+
+	_, err := env.OperatorClient().CreateNexusEndpoint(ctx, &operatorservice.CreateNexusEndpointRequest{


You could consider leveraging NexusTestEnv like a lot of the other Nexus tests; it has a createRandomExternalNexusServer and more already.

I'll keep that in mind for future tests. For now, I'm inclined to keep this more verbose and explicit. But if I ever need to modify this code, I'll look into simplifying it with existing or new test helpers. (But I'm still trying to build muscle memory re: Nexus registration mechanics, and understanding the parts of the RPC handshake, etc.)

stephanos · 2026-05-13T01:04:34Z

+
+var LongPollTimeout = dynamicconfig.NewNamespaceDurationSetting(
+	"callback.longPollTimeout",
+	20*time.Second,


Let's make that a constant in common/constants.go, too, while we're at it.

chrsmith

Still working on the feedback (thanks!)

When I'm finished I'll split this all up into a series of smaller PRs applied to a feature branch. That'll make it easier to understand and review the changes.

chrsmith · 2026-05-13T22:49:37Z

+		"RequestID": c.RequestId,
+		// Only set for standalone callbacks.
+		"CallbackID": c.CallbackId,


Good catch, I missed that.

chrsmith · 2026-05-13T23:02:36Z

 	}

+	// Setup the completion's headers.
+	completion.Header = callback.Header


It is for one of the cases (internal or outbound, I don't recall off the top of my head). Let's go over this in a separate PR after I've split this across.

This change came from applying a suggestion Stpehan suggested that might need some more thought to do safely.

chrsmith · 2026-05-13T23:11:19Z

+	// This shouldn't happen outside of tests, since the Nexus machinery
+	// would prevent an invalid transition anyways. (e.g. terminating
+	// an already terminated Callback.)
+	if c.LifecycleState(ctx).IsClosed() {


Yup, sorry about that.

chrsmith · 2026-05-13T23:21:29Z

+
+// completionSource returns the completionSource from the callback, which depends on whether it
+// is embedded or is running in standalone mode.
+func (c *Callback) completionSource(ctx chasm.Context) CompletionSource {


Good point! I'll just have Callback implement CompletionSource, and then just call that.

chrsmith · 2026-05-14T20:41:37Z

@bergundy , @stephanos I've addressed all the feedback so far and rebased.

The only meaningful change was I backed out moving some of the "outbound request setup logic" from Callback.loadInvocationArgs back to invocableOutbound.Invoke. (It's a good refactoring to take, but I don't feel confident enough that it was safe and accounted for all the possible edge cases.)

Will ping folks on Slack if we should just do another review here, or if I should push a series of smaller PRs into a feature branch.

## What changed? Mark `DescribeNexusOperationRequest` as long poll API category. ## Why? I response to #10192 (comment)

bergundy

I reviewed everything but standalone_callbacks_test.go. This is getting really close to done.

bergundy · 2026-05-15T17:28:20Z

+		// requestID (unique per API call) + idx (position within the request) ensures unique, idempotent callback IDs.
 		id := fmt.Sprintf("%s-%d", requestID, idx)
-		callbackObj := callback.NewCallback(requestID, registrationTime, &callbackspb.CallbackState{}, chasmCB)
+		callbackObj := callback.NewEmbeddedCallback(requestID, registrationTime, chasmCB)


I would also accept the constructor taking a chasm context and extracting the time but what you have is fine too.

Ack. I'll keep that in mind if I need to modify this in the future, but for now I'll just keep it as-is.

bergundy · 2026-05-15T17:44:53Z

+	return map[string]string{
+		"request-id": c.RequestId,
+		// Only set for standalone callbacks.
+		"callback-id": ctx.ExecutionKey().BusinessID,


nit: ContextMetadata is only called on the root component, the comment makes it sound like that's not the case.

I removed that comment, and moved it to the function declaration.

// ContextMetadata is used for root CHASM components, so this is only applicable // for the standalone callback case. func (c *Callback) ContextMetadata(ctx chasm.Context) map[string]string {

I know it might be cleaner to just drop the comment all together, but IMHO it's important to call out any differences between the embedded vs. standalone case. (What do you think? Do you agree, or is this just noise? I'm still norming on what sort of things to call out.)

bergundy · 2026-05-15T17:46:04Z

 }
+
+func callbackCompletionToNexusCompleteOperationOpts(
+	cb *Callback,


nit: this can be a method on Callback.

I'm inclined to leave this as-is, because I can't think of a good clean way to add it without adding more error handling. (Since the function would need to check if the Callback is in embedded mode or not.)

bergundy · 2026-05-15T17:46:53Z

+	case *callbackpb.CallbackExecutionCompletion_Failure:
+		f, err := commonnexus.TemporalFailureToNexusFailure(completion.GetFailure())
+		if err != nil {
+			wrappedErr := fmt.Errorf("failed to convert failure: %w", err)
+			return nexusrpc.CompleteOperationOptions{}, wrappedErr
+		}
+		opErr := &nexus.OperationError{
+			State:   nexus.OperationStateFailed,
+			Message: "operation failed",
+			Cause:   &nexus.FailureError{Failure: f},
+		}
+		if err := nexusrpc.MarkAsWrapperError(nexusrpc.DefaultFailureConverter(), opErr); err != nil {
+			wrappedErr := fmt.Errorf("failed to mark wrapper error: %w", err)
+			return nexusrpc.CompleteOperationOptions{}, wrappedErr
+		}
+		nexusCompletion.Error = opErr
+		return nexusCompletion, nil


FYI, I'm tracking this as tech debt. We don't want to have to do all of this conversion every time we extract a completion from a component.

Thanks, and agreed. This can probably be standardized across all CHASM components.

bergundy · 2026-05-15T17:47:31Z

+		return nexusCompletion, nil
+
+	default:
+		return nexusrpc.CompleteOperationOptions{}, serviceerror.NewInvalidArgument("no completion result provided")


This is an internal error, it's our fault not the user's fault.

bergundy · 2026-05-15T22:53:37Z

+		// Assert info object is updated.
+		require.Equal(t, callbackspb.CALLBACK_STATUS_SUCCEEDED, callback.StateMachineState())
+		require.Equal(t, int32(2), callback.Attempt)
+		require.Nil(t, callback.LastAttemptFailure)


This should not reset the field if it existed before. For SAA we use a message that stored the last attempt failure time to preserve as much of the last failure as possible. I would do that here too, can wait for a follow up PR given that it changes existing behavior.

Makes sense. It's an easy change to make, done.

bergundy · 2026-05-15T22:55:03Z

+		t.Run(test.Name, func(t *testing.T) {
+			currentTime := time.Now().UTC()
+			mctx := &chasm.MockMutableContext{}
+			mctx.HandleNow = func(chasm.Component) time.Time { return currentTime }


nit: This could be initialized directly as a field on the mutable context struct literal.

I'll just keep it as is, none of these seem strictly better IMHO.

mctx := &chasm.MockMutableContext{MockContext: chasm.MockContext{HandleNow: func(chasm.Component) time.Time { return currentTime }}} mctx := &chasm.MockMutableContext{MockContext: chasm.MockContext{ HandleNow: func(chasm.Component) time.Time { return currentTime }, }} mctx := &chasm.MockMutableContext{ MockContext: chasm.MockContext{ HandleNow: func(chasm.Component) time.Time { return currentTime }, }, }

bergundy · 2026-05-15T23:05:53Z

+const (
+	// Copy of common/nexus.CallbackTokenHeader, to avoid import cycle.
+	// Header to identify the callback being resolved for callbacks to resolve Nexus operations.
+	commonnexusCallbackTokenHeader = "Temporal-Callback-Token"


Ah, I forgot that this header was Temporal specific and not generic Nexus. I'd be fine if you moved the logic into the Temporal part of the codebase.

I would also love for us to use a Temporal agnostic header field for this but we should do that as a separate step.

Another thing we should do is make the token structured in the CompletionRequest struct and prevent the need to extract it from header in our handler implementation.

OK, I'll back out the changes to nexusrpc/ and just set the required header in callback/invocable_outbound.go like before. As far as how to improve this, let's chat about that in a separate PR.

I'm definitely onboard with refactoring this, since the "headers x { Callback, Operation } Token" x { Caller, Temporal, Handler }" situation is certainly hard to keep straight.

bergundy · 2026-05-15T23:12:06Z

+// ErrOperationNotStarted is returned when a completion arrives before the operation has
+// started and no operation token is provided. This error is used by the callback invocation
+// layer to detect this specific condition and retry without triggering the circuit breaker.
+var ErrOperationNotStarted = serviceerror.NewFailedPrecondition("nexus operation not started")


I suggest that you create a new server internal service error with the FailedPrecondition status code and use a type assertion from the frontend handler to translate this error to a non retryable Nexus handler error.

I think I did that right, but please double check the commit that wired it in.

Specifically, the code is returning a &serviceerror.NexusOperationNotStarted{}. But this isn't a GRPC error wrapping that NexusOperationNotStarted. (So I don't think any sort of "failed precondition" would get surfaced upstream.)

bergundy · 2026-05-15T23:19:00Z

+	// reject the request. This handles the race where a completion arrives before the start
+	// handler returns with the operation token. The caller will retry and by then the start
+	// handler will have returned and recorded the token.
+	if operationToken == "" {


We need a follow up to delay the completion request using chasm.PollComponent for a second to allow the start request to be recorded. I don't want these errors showing up for users.

OK. I filed https://temporalio.atlassian.net/browse/NEXUS-369 to track that.

I tried to write a unit test to confirm the current behavior, but inside invocable_outbound.go we only retry these errors IFF the callback URL is temporal://system. So I'd need to spend more time figuring out how we can simulate that within functional or integration tests.

I did add unit tests for invocable_outbound.go to cover that case, but that isn't where we'd want to have that logic.

chrsmith · 2026-05-18T18:57:16Z

I think I got to everything. However, I believe the way I wired in the serviceerror.NexusOperationNotStartedFailure isn't quite what you were asking for @bergundy .

However, I assume the way we are surfacing errors is fine for the time being, until we can address NEXUS-369: Improve "callback invoked before Nexus operation started" situation, which would entail adding some sort of delay or polling to start the callback until the target Nexus operation has actually started. WDYT?

chrsmith force-pushed the chrsmith/standalone-callbacks_ii branch 2 times, most recently from 0d3b36b to ad9f7cb Compare May 7, 2026 21:21

chrsmith changed the title ~~[Draft] Standalone Callbacks - II~~ [Draft] Add support for standalone callbacks May 7, 2026

stephanos self-requested a review May 7, 2026 21:37

chrsmith requested a review from Quinn-With-Two-Ns May 7, 2026 21:40

chrsmith force-pushed the chrsmith/standalone-callbacks_ii branch from edb387a to 40f2f7e Compare May 7, 2026 22:01

stephanos reviewed May 8, 2026

View reviewed changes

chrsmith mentioned this pull request May 11, 2026

Add Standalone Callbacks (rebase) temporalio/api#774

Open

chrsmith requested a review from bergundy May 11, 2026 21:21

bergundy reviewed May 12, 2026

View reviewed changes

stephanos reviewed May 13, 2026

View reviewed changes

chrsmith commented May 13, 2026

View reviewed changes

stephanos mentioned this pull request May 14, 2026

DescribeNexusOperationRequest as long poll category #10256

Merged

chrsmith added 16 commits May 14, 2026 13:17

Implement standalone callbacks

89b9fe8

Test updates

047a6e8

Refactor standalone_callbacks_test.go to use testcore.NewEnv

2410731

Expanding statemachine_test.go coverage

e7bd633

Address race when completing an unstarted Nexus operation

9aea1a6

Address PR feedback

9788a82

Count DescribeCallbackExecution as long poll as applicable

34ca85f

Address PR feedback

e4cad82

Address PR feedback

e462fae

Address PR feedback

684eae8

Move snippet to loadInvocationArgs

e6d586b

Address PR feedback

32bd8e0

Wire Identity field to TerminateFailureInfo

1076a59

Refactor to table-driven test

e117578

Address PR feedback

62ce872

PR feedback from /review bot

b800cdd

chrsmith requested review from a team as code owners May 14, 2026 20:39

chrsmith changed the title ~~[Draft] Add support for standalone callbacks~~ Add support for standalone callbacks May 14, 2026

Address lint warnings

a17e9ad

stephanos added a commit that referenced this pull request May 15, 2026

DescribeNexusOperationRequest as long poll category (#10256)

d2ed7f1

## What changed? Mark `DescribeNexusOperationRequest` as long poll API category. ## Why? I response to #10192 (comment)

Address PR feedback from /review

9a0ee41

chrsmith force-pushed the chrsmith/standalone-callbacks_ii branch from bf79b70 to 9a0ee41 Compare May 15, 2026 16:49

Fix bug in setting wrong headers for resolving Nexus op callbacks

0dc272d

chrsmith requested a review from bergundy May 15, 2026 17:05

bergundy reviewed May 15, 2026

View reviewed changes

chrsmith added 12 commits May 16, 2026 10:12

Merge branch 'main' into chrsmith/standalone-callbacks_ii

0073f22

Use new LongPoll* constants

6a8b8ce

Address minor PR feedback

8e73d57

Only set TerminalFailure for external errors

9990104

Do not clear LastAttemptFailure on successful Callback

2fb8a64

Backout the Temporal NexusCallbackToken from nexusrpc

bf3954e

Address PR feedback

908b9c7

Update go.mod to latest version of api-go SHA

47df7d7

Use serviceerror.NexusOperationNotStarted

04033c1

Migrate from EventuallyWithT to Await

d5218c4

Add unit tests for invocable_outbound

ad00970

Merge branch 'main' into chrsmith/standalone-callbacks_ii

e19e080

chrsmith added 2 commits May 18, 2026 12:00

Remove no longer applicable comment

a1427e1

Reword comment slightly

36c7134

chrsmith requested a review from bergundy May 18, 2026 19:14

chrsmith added 2 commits May 18, 2026 14:20

Rerun 'make proto' to sync .pb.go with actual defs

78dc137

Update callbacks test to match new behavior

f1b13e2

	// Callback was terminated by request.
	// Callback was terminated by request. Only relevant for standalone callbacks.

	type requiredField struct {
	type requiredStringField struct {

	// aysynchronous actions that take place outside of Temporal. (e.g. waiting for a payment to
	// asynchronous actions that take place outside of Temporal. (e.g. waiting for a payment to

		ctx, cancel := context.WithTimeout(context.Background(), time.Second*30)
		defer cancel()

Conversation

chrsmith commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed?

Why?

How did you test it?

Potential risks

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stephanos May 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

chrsmith commented May 11, 2026

Uh oh!

bergundy left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stephanos May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stephanos May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrsmith commented May 7, 2026 •

edited

Loading

stephanos May 11, 2026 •

edited

Loading

stephanos May 13, 2026 •

edited

Loading

stephanos May 13, 2026 •

edited

Loading