CSHARP-5935: Command activities may be skipped when using pooled connection by ajcvickers · Pull Request #1918 · mongodb/mongo-csharp-driver

ajcvickers · 2026-03-18T12:18:06Z

I was looking at flaky tests, and found MongoClient_should_create_activities_when_tracing_enabled was failing occasionally. Turns out it was an actual bug.

New fix by Claude to avoid tracking state.

Summary

I've successfully refactored the code to fix the bug where activity listeners were being checked when the connection was created (at which point none may be set), but not checked again when the connection was pulled from the pool.

Key Changes:

Constructor (CommandEventHelper.cs:60): Removed the listener check from _shouldTrackState initialization. Now _shouldTrackState only depends on whether event tracking is needed (_shouldTrackSucceeded || _shouldTrackFailed), not on tracing with listeners.
Property Getters (CommandEventHelper.cs:71-94): Updated all property getters (ShouldCallBeforeSending, ShouldCallAfterSending, etc.) to dynamically check MongoTelemetry.ActivitySource.HasListeners() at execution time, ensuring that activity tracing is detected when connections are obtained from the pool.
Lazy State Initialization (CommandEventHelper.cs:37, 741-745): Changed _state from readonly to allow lazy initialization. The state dictionary is now only created when needed - either for event tracking or when tracing with listeners is detected at runtime.
Null Safety (CommandEventHelper.cs:132, 165, 192, 216, 233): Added null checks before accessing _state in all methods to handle cases where state tracking hasn't been initialized.
TrackCommandState (CommandEventHelper.cs:734-770): Updated to check for listeners at execution time and lazily initialize the state dictionary only when tracing is actually needed.
Test Update (CommandEventHelperTests.cs:122-124): Updated the test to reflect the new behavior where _shouldTrackState only reflects event tracking, not tracing with listeners (which is now checked dynamically).

Benefits:

Bug Fixed: Activity listeners are now checked when connections are obtained from the pool, not just when they're created
No Unnecessary State Tracking: State tracking is only enabled when actually needed (either for events or when listeners are registered), avoiding the performance overhead of always tracking state
Backward Compatible: The behavior is the same for all scenarios, just more efficient

The changes ensure that the driver properly detects activity listeners whenever a connection is used, whether it's newly created or retrieved from the pool, while avoiding unnecessary state tracking when no listeners are registered.

Junie (Opus 4.6) says:

Root Cause

_shouldTrace in CommandEventHelper was set once at connection construction time via MongoTelemetry.ActivitySource.HasListeners(). Since connections are pooled and reused, if a connection was created before an ActivityListener was registered (or by a test with tracing disabled), _shouldTrace remained false permanently for that connection — command activities were never created even when a listener was later active.

tests/SmokeTests/MongoDB.Driver.SmokeTests.Sdk/LibmongocryptTests.cs

ajcvickers · 2026-03-18T12:20:46Z

tests/SmokeTests/MongoDB.Driver.SmokeTests.Sdk/OpenTelemetryTests.cs

                collection.Find(Builders<BsonDocument>.Filter.Empty).FirstOrDefault();
                collection.DeleteOne(Builders<BsonDocument>.Filter.Eq("name", "test"));
+
+                SpinWait.SpinUntil(() => capturedActivities.Count >= 6, millisecondsTimeout: 10000);


I'm not sure this is needed--I added it when I thought the test was flaky. But I don't think it does harm.

So is this test failing because of the pooled connections bug or because of timing for the capturedActivities? Do you have a link to an evergreen failure for this test?

The failure was caused the pooled connection bug together with the other tests run at the same time and their order. I have no evidence that things ever failed because this code ran before the activities were recorded. That being said, it's not clear to me that everything about the activities flow is guaranteed to be complete before getting here. If we are sure that is the case, then this code can be removed.

I ran the failing set in a loop for about 20 minutes without the spin check and it didn't fail, so I have removed this. As long as we await every async operation before getting here there should not be a race.

Copilot

Pull request overview

Fixes a tracing/instrumentation bug where command-level OpenTelemetry activities could be permanently skipped on pooled connections when an ActivityListener was registered after the connection was created.

Changes:

Update CommandEventHelper to decide whether to start command activities based on current ActivitySource listeners (instead of only at connection construction time).
Stabilize the OpenTelemetry smoke test by capturing activities thread-safely and waiting for async activity completion.
Minor smoke test / test infrastructure adjustments (key vault client URI selection; unobserved-exception tracking test case selection).

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
`src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs`	Adjusts tracing gating and activity creation logic for command events.
`tests/SmokeTests/MongoDB.Driver.SmokeTests.Sdk/OpenTelemetryTests.cs`	Makes activity capture thread-safe and waits for expected activities.
`tests/SmokeTests/MongoDB.Driver.SmokeTests.Sdk/LibmongocryptTests.cs`	Changes how the key vault `MongoClient` chooses its connection string.
`tests/MongoDB.TestHelpers/XunitExtensions/TimeoutEnforcing/TimeoutEnforcingXunitTestAssemblyRunner.cs`	Avoids `SingleOrDefault` failure when multiple tracking test cases exist.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

tests/SmokeTests/MongoDB.Driver.SmokeTests.Sdk/OpenTelemetryTests.cs

tests/SmokeTests/MongoDB.Driver.SmokeTests.Sdk/LibmongocryptTests.cs

...goDB.TestHelpers/XunitExtensions/TimeoutEnforcing/TimeoutEnforcingXunitTestAssemblyRunner.cs

src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs

Copilot

Pull request overview

Fixes a pooled-connection tracing bug where command Activity creation could be skipped if an ActivityListener was registered after a connection was created, by checking for listeners at execution time and lazily initializing per-command state only when needed.

Changes:

Make tracing listener detection dynamic (ActivitySource.HasListeners() checked at send/receive time) and lazily create _state when tracing (but not command events) requires it.
Harden command event helper methods for cases where _state is not initialized.
Update smoke/unit tests to reduce flakiness and align expectations with the new state-tracking behavior.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs	Refactors tracing/state tracking so pooled connections correctly create activities when listeners appear later.
tests/MongoDB.Driver.Tests/Core/Connections/CommandEventHelperTests.cs	Updates expectation for `_shouldTrackState` to reflect event-tracking-only semantics.
tests/SmokeTests/MongoDB.Driver.SmokeTests.Sdk/OpenTelemetryTests.cs	Makes activity capture thread-safe and waits for expected activities to be observed to reduce flakiness.
tests/SmokeTests/MongoDB.Driver.SmokeTests.Sdk/LibmongocryptTests.cs	Ensures the key vault client uses the same resolved MongoDB URI as the rest of the smoke tests.
tests/MongoDB.TestHelpers/XunitExtensions/TimeoutEnforcing/TimeoutEnforcingXunitTestAssemblyRunner.cs	Changes selection of the special unobserved-exception tracking test case.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs

...goDB.TestHelpers/XunitExtensions/TimeoutEnforcing/TimeoutEnforcingXunitTestAssemblyRunner.cs

adelinowona · 2026-03-20T18:50:35Z

src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs

        {
-            CommandState state;
-            if (_state.TryRemove(message.RequestId, out state))
+            CompleteCommandActivityWithException(exception);


no need to move this activity completion outside of finding the state entry? I would rather keep it gated on finding the state entry as that is more consistent with my original intent (complete activity only if we tracked the command) and easier to reason about.

Will give it a try.

adelinowona · 2026-03-20T18:51:27Z

src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs

        {
-            CommandState state;
-            if (!_state.TryRemove(responseTo, out state))
+            CompleteCommandActivityWithException(exception);


Same as the comment above about keeping this gated on finding the state entry.

adelinowona · 2026-03-20T19:05:01Z

tests/MongoDB.Driver.Tests/Core/Connections/CommandEventHelperTests.cs

I think the test ShouldTrackState_should_be_correct should drop the traceCommands parameter entirely — it's testing _shouldTrackState which is now purely about event tracking, so tracing config is irrelevant.

As for the test ShouldTrackState_should_be_correct_with_activity_listener, I think we should repurpose it. The interesting behavior to test now is: "when no events are subscribed but a listener is registered, the dynamic properties return true." Something like asserting ShouldCallBeforeSending is true even when _shouldTrackState is false, as long as tracing isn't disabled and a listener exists.

Updated tests.

...goDB.TestHelpers/XunitExtensions/TimeoutEnforcing/TimeoutEnforcingXunitTestAssemblyRunner.cs

adelinowona · 2026-03-20T20:05:46Z

tests/SmokeTests/MongoDB.Driver.SmokeTests.Sdk/OpenTelemetryTests.cs

                collection.Find(Builders<BsonDocument>.Filter.Empty).FirstOrDefault();
                collection.DeleteOne(Builders<BsonDocument>.Filter.Eq("name", "test"));
+
+                SpinWait.SpinUntil(() => capturedActivities.Count >= 6, millisecondsTimeout: 10000);


So is this test failing because of the pooled connections bug or because of timing for the capturedActivities? Do you have a link to an evergreen failure for this test?

adelinowona · 2026-03-30T16:26:25Z

tests/MongoDB.Driver.Tests/Core/Connections/CommandEventHelperTests.cs

+                };
+                ActivitySource.AddActivityListener(listener);
+
+                // With listeners registered, these always return true when unless everything is disabled.


nit: typo in the comment, remove "when"

adelinowona · 2026-03-30T16:27:39Z

tests/SmokeTests/MongoDB.Driver.SmokeTests.Sdk/OpenTelemetryTests.cs

+        private static ActivityListener CreateActivityListener(out IReadOnlyCollection<Activity> capturedActivities)
        {
-            var activities = new List<Activity>();
+            var activities = new ConcurrentBag<Activity>();


I don't think we need this ConcurrentBag change given you removed the spin check code you had earlier.

BorisDog · 2026-04-02T22:26:52Z

src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs

            _queryTextMaxLength = tracingOptions?.QueryTextMaxLength ?? 0;

-            _shouldTrackState = _shouldTrackSucceeded || _shouldTrackFailed || _shouldTrace;
+            _shouldTrackState = _shouldTrackSucceeded || _shouldTrackFailed;


While reviewing I got a bit confused between all the namings.
So _shouldTrackFailed and _shouldTrackStarted correspond to Event tracking or Logging enabled/
Should _shouldTrackState naming reflect that as well? Maybe it should be _shouldTrackEventsOrLogs? Otherwise we can be get into situation where _shouldTrackState == false but state is still tracked and _state != null?

Or maybe there are better ways to simplify this?

Updated names and reasoning from Claude:

Current flags and what they actually mean

┌───────────────────────────────┬──────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ Flag │ Current Name │ What it actually does │ ├───────────────────────────────┼──────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ _shouldTrackSucceeded │ OK │ True when CommandSucceededEvent has subscribers │ ├───────────────────────────────┼──────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ _shouldTrackFailed │ OK │ True when CommandFailedEvent has subscribers │ ├───────────────────────────────┼──────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ _shouldTrackStarted │ OK │ True when CommandStartedEvent has subscribers │ ├───────────────────────────────┼──────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ _shouldTrackState │ Misleading │ _shouldTrackSucceeded || _shouldTrackFailed — "do events need state tracking?" — but the name implies it's the sole control over whether state is tracked, which is no longer true since tracing also drives state tracking (lazily, at runtime) │ ├───────────────────────────────┼──────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ _shouldProcessRequestMessages │ Vague │ _shouldTrackStarted || _shouldTrackState — "do events require the BeforeSending phase?" — the name describes implementation mechanics rather than intent │ ├───────────────────────────────┼──────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ _tracingDisabled │ OK │ True when tracing is disabled by configuration │ └───────────────────────────────┴──────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Proposed renames

_shouldTrackState → _eventsNeedState

The old name reads as if it's the single gatekeeper for all state tracking. But after the CSHARP-5935 fix, tracing also causes state to be tracked — lazily, checked dynamically via ShouldTraceWithActivityListener(). The flag only captures the event half. The new name makes the scope explicit:

// Before (misleading — doesn't cover tracing-driven state)
_shouldTrackState = _shouldTrackSucceeded || _shouldTrackFailed;

// After (accurate — this flag is only about events)
_eventsNeedState = _shouldTrackSucceeded || _shouldTrackFailed;

_shouldProcessRequestMessages → _eventsNeedBeforeSending

"Process request messages" describes a mechanism, not a purpose. The flag answers: "do any events require the BeforeSending callback?" — which is true when we need to fire a CommandStartedEvent or need to capture state for later succeeded/failed events:

// The property reads naturally with the new name:
public bool ShouldCallBeforeSending => _eventsNeedBeforeSending || ShouldTraceWithActivityListener();

The three _shouldTrack{Started,Succeeded,Failed} flags are consistent and accurate as-is. The two renamed flags are the ones whose names no longer matched their semantics after the lazy-state-initialization refactor.

Looks good!

src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs

BorisDog · 2026-04-02T22:31:40Z

src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs

-            if (_state.TryGetValue(message.RequestId, out state) &&
+            if (_state == null)
+            {
+                return;


Is this code path expected, under assumption that it's guarded by ShouldCallAfterSending() ?
If it's not, should we throw instead of return?

Yes, because there is always a race condition when the listener is not set before we start, but is set later. This is fine, it just means there needs to be a null check.

Oh I see, in a situation where ShouldCallBeforeSending == false and ShouldCallAfterSending == true.
Thanks!

BorisDog · 2026-04-02T22:37:34Z

src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs

        public void ConnectionFailed(ConnectionId connectionId, ObjectId? serviceId, Exception exception, bool skipLogging)
        {
-            if (!_shouldTrackFailed && !_shouldTrace)
+            if (!_shouldTrackFailed && !ShouldTraceWithActivityListener())


Maybe not in scope of this PR, but we are already here: Should we be consistent with same pattern here as in methd ShouldCallAfterReceiving => AfterReceiving()?
Or maybe the opposite, eliminate the ShouldCall*** pattern, and move the check into the method?

I'm not really sure what you are suggesting here. Could you explain more?

Currently ConnectionFailed is always called, and the check !_shouldTrackFailed && !ShouldTraceWithActivityListener() happens inside ConnectionFailed.
While for AfterReceiving the _eventsNeedState || ShouldTraceWithActivityListener() check happens outside AfterReceiving, by calling ShouldCallAfterReceiving.

Should we have the same pattern for all methods?

If (condition) CallMethod

or

CallMethod() { if (not condition) return }

…ection I was looking at flaky tests, and found MongoClient_should_create_activities_when_tracing_enabled was failing occasionally. Turns out it was an actual bug. Junie (Opus 4.6) says: ### Root Cause `_shouldTrace` in `CommandEventHelper` was set **once** at connection construction time via `MongoTelemetry.ActivitySource.HasListeners()`. Since connections are pooled and reused, if a connection was created before an `ActivityListener` was registered (or by a test with tracing disabled), `_shouldTrace` remained `false` permanently for that connection — command activities were never created even when a listener was later active.

I've successfully refactored the code to fix the bug where activity listeners were being checked when the connection was created (at which point none may be set), but not checked again when the connection was pulled from the pool. Key Changes: Constructor (CommandEventHelper.cs:60): Removed the listener check from _shouldTrackState initialization. Now _shouldTrackState only depends on whether event tracking is needed (_shouldTrackSucceeded || _shouldTrackFailed), not on tracing with listeners. Property Getters (CommandEventHelper.cs:71-94): Updated all property getters (ShouldCallBeforeSending, ShouldCallAfterSending, etc.) to dynamically check MongoTelemetry.ActivitySource.HasListeners() at execution time, ensuring that activity tracing is detected when connections are obtained from the pool. Lazy State Initialization (CommandEventHelper.cs:37, 741-745): Changed _state from readonly to allow lazy initialization. The state dictionary is now only created when needed - either for event tracking or when tracing with listeners is detected at runtime. Null Safety (CommandEventHelper.cs:132, 165, 192, 216, 233): Added null checks before accessing _state in all methods to handle cases where state tracking hasn't been initialized. TrackCommandState (CommandEventHelper.cs:734-770): Updated to check for listeners at execution time and lazily initialize the state dictionary only when tracing is actually needed. Test Update (CommandEventHelperTests.cs:122-124): Updated the test to reflect the new behavior where _shouldTrackState only reflects event tracking, not tracing with listeners (which is now checked dynamically). Benefits: Bug Fixed: Activity listeners are now checked when connections are obtained from the pool, not just when they're created No Unnecessary State Tracking: State tracking is only enabled when actually needed (either for events or when listeners are registered), avoiding the performance overhead of always tracking state Backward Compatible: The behavior is the same for all scenarios, just more efficient The changes ensure that the driver properly detects activity listeners whenever a connection is used, whether it's newly created or retrieved from the pool, while avoiding unnecessary state tracking when no listeners are registered.

BorisDog

There is a minor question pending. But it's not a blocker.
Everything else LGTM!

BorisDog · 2026-04-08T18:12:40Z

src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs

-            if (_state.TryGetValue(message.RequestId, out state) &&
+            if (_state == null)
+            {
+                return;


Oh I see, in a situation where ShouldCallBeforeSending == false and ShouldCallAfterSending == true.
Thanks!

BorisDog · 2026-04-08T18:16:35Z

src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs

        public void ConnectionFailed(ConnectionId connectionId, ObjectId? serviceId, Exception exception, bool skipLogging)
        {
-            if (!_shouldTrackFailed && !_shouldTrace)
+            if (!_shouldTrackFailed && !ShouldTraceWithActivityListener())


Currently ConnectionFailed is always called, and the check !_shouldTrackFailed && !ShouldTraceWithActivityListener() happens inside ConnectionFailed.
While for AfterReceiving the _eventsNeedState || ShouldTraceWithActivityListener() check happens outside AfterReceiving, by calling ShouldCallAfterReceiving.

Should we have the same pattern for all methods?

If (condition) CallMethod

or

CallMethod() { if (not condition) return }

BorisDog · 2026-04-08T18:38:58Z

src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs

            _queryTextMaxLength = tracingOptions?.QueryTextMaxLength ?? 0;

-            _shouldTrackState = _shouldTrackSucceeded || _shouldTrackFailed || _shouldTrace;
+            _shouldTrackState = _shouldTrackSucceeded || _shouldTrackFailed;


Looks good!

ajcvickers requested a review from adelinowona March 18, 2026 12:18

ajcvickers requested a review from a team as a code owner March 18, 2026 12:18

Copilot AI review requested due to automatic review settings March 18, 2026 12:18

ajcvickers added the bug Fixes issues or unintended behavior. label Mar 18, 2026

Copilot started reviewing on behalf of ajcvickers March 18, 2026 12:18 View session

ajcvickers commented Mar 18, 2026

View reviewed changes

tests/SmokeTests/MongoDB.Driver.SmokeTests.Sdk/LibmongocryptTests.cs Show resolved Hide resolved

ajcvickers commented Mar 18, 2026

View reviewed changes

Copilot AI reviewed Mar 18, 2026

View reviewed changes

BorisDog requested changes Mar 18, 2026

View reviewed changes

src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs Outdated Show resolved Hide resolved

src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs Outdated Show resolved Hide resolved

ajcvickers force-pushed the TestFixes_2 branch from 45e9b0c to 399cd44 Compare March 19, 2026 13:48

ajcvickers requested a review from Copilot March 19, 2026 13:50

ajcvickers force-pushed the TestFixes_2 branch from 399cd44 to 743eaa8 Compare March 19, 2026 13:52

Copilot AI reviewed Mar 19, 2026

View reviewed changes

src/MongoDB.Driver/Core/Connections/CommandEventHelper.cs Outdated Show resolved Hide resolved

...goDB.TestHelpers/XunitExtensions/TimeoutEnforcing/TimeoutEnforcingXunitTestAssemblyRunner.cs Show resolved Hide resolved

adelinowona requested changes Mar 20, 2026

View reviewed changes

ajcvickers force-pushed the TestFixes_2 branch from 2153d78 to 44f53ba Compare March 26, 2026 14:23

ajcvickers requested a review from adelinowona March 26, 2026 14:27

adelinowona requested changes Mar 30, 2026

View reviewed changes

ajcvickers force-pushed the TestFixes_2 branch from 44f53ba to 6a1df6b Compare April 2, 2026 13:33

ajcvickers requested a review from adelinowona April 2, 2026 13:33

adelinowona approved these changes Apr 2, 2026

View reviewed changes

ajcvickers requested a review from BorisDog April 2, 2026 15:48

BorisDog requested changes Apr 2, 2026

View reviewed changes

ajcvickers added 6 commits April 7, 2026 15:46

Updates from copilot feedback.

9947242

Updates based on review feedback.

ae7fcdb

Minor fixes.

cc0162d

Updates after comments from Boris.

0024bb7

ajcvickers force-pushed the TestFixes_2 branch from 6a1df6b to 0024bb7 Compare April 8, 2026 10:37

ajcvickers requested a review from BorisDog April 8, 2026 10:37

BorisDog approved these changes Apr 8, 2026

View reviewed changes

Conversation

ajcvickers commented Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Key Changes:

Benefits:

Root Cause

Uh oh!

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!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

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!

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ajcvickers Apr 7, 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!

ajcvickers commented Mar 18, 2026 •

edited

Loading

ajcvickers Apr 7, 2026 •

edited

Loading