SOLR-16458: Migrate NodeHealthAPI from homegrown @EndPoint to JAX-RS by epugh · Pull Request #4171 · apache/solr

epugh · 2026-02-28T13:08:36Z

Migrates NodeHealthAPI — the last node-level V2 API still using Solr's homegrown @EndPoint annotation — to standard JAX-RS, following the same pattern as NodeLogging, GetPublicKey, etc.

Design

The logic stays in HealthCheckHandler (minimising diff surface). NodeHealthAPI is a thin JAX-RS wrapper (~60 lines) that delegates entirely to it.

Key changes

solr/api — New NodeHealthApi interface (@Path, @GET, @Operation) and NodeHealthResponse model (status, message, num_cores_unhealthy)
NodeHealthAPI — Replaces @EndPoint with JAX-RS; injects CoreContainer, delegates to HealthCheckHandler
HealthCheckHandler — Logic unchanged; adds public NodeHealthResponse checkNodeHealth(Boolean, Integer) as the shared entry point for both v1 (handleRequestBody) and v2 (NodeHealthAPI); switches to getJerseyResources() / empty getApis()
V2NodeAPIMappingTest — Removes the now-obsolete @EndPoint/ApiBag routing test for health
NodeHealthAPITest — New Mockito unit tests for the API class
NodeHealthAPITest2 — New mock-free integration tests: cloud-mode via real MiniSolrCloudCluster, legacy mode via embedded CoreContainer built from NodeConfig
implicit-requesthandlers.adoc — Health section now links to both HealthCheckHandler (v1) and NodeHealthAPI (v2) javadocs

Co-authored-by: epugh <22395+epugh@users.noreply.github.com>

…ef guide Co-authored-by: epugh <22395+epugh@users.noreply.github.com>

epugh · 2026-02-28T13:21:36Z

Some outstanding questions: 1) there is a more mock and less mock versions of the same test. Which do we prefer? 2) Does this seem like a reasonable pattern for the conversion?

epugh · 2026-02-28T13:27:50Z

I wish I didnt' have TWO ways of writing tests, one for cloud and one for standalone... sigh.

solr/api/src/java/org/apache/solr/client/api/model/NodeHealthResponse.java

solr/core/src/java/org/apache/solr/handler/admin/HealthCheckHandler.java

epugh · 2026-03-01T20:53:59Z

tests all pass!

gerlowskija · 2026-03-03T13:34:39Z

@epugh - this should probably be attached to one of the v2 JIRA tickets or another. Maybe https://issues.apache.org/jira/browse/SOLR-16458?

epugh · 2026-03-03T13:37:44Z

@epugh - this should probably be attached to one of the v2 JIRA tickets or another. Maybe https://issues.apache.org/jira/browse/SOLR-16458?

Sure... I suppose I could be crosslinking all of these to various JIRAs?

changelog/unreleased/SOLR-16458-migrate-node-health-api.yml

changelog/unreleased/migrate-node-health-api.yml

solr/api/src/java/org/apache/solr/client/api/endpoint/NodeHealthApi.java

solr/api/src/java/org/apache/solr/client/api/model/NodeHealthResponse.java

gerlowskija · 2026-03-03T14:37:47Z

solr/core/src/test/org/apache/solr/handler/admin/api/NodeHealthAPITest.java

+ * mocks.
+ *
+ * <p>Cloud-mode tests use a real {@link org.apache.solr.cloud.MiniSolrCloudCluster} and get a
+ * {@link CoreContainer} directly from a {@link JettySolrRunner}. Legacy (standalone) mode tests


[Q] Do we have other tests that do standalone testing within a SolrCloudTestCase?

It feels weird conceptually. And in practical terms SolrCloudTestCase does some work that makes it much slower on a per-test basis than our other base classes. Doing standalone testing in a SolrCloudTestCase is going to end up paying that runtime cost for no reason.

Dunno... Do you think we should ahve TWO tests? The setup is only done one in beforeClass.. not per test.

Do you think we should ahve TWO tests?

Yes, probably. NodeHealthAPIStandaloneTest and NodeHealthAPICloudTest or something like that.

gerlowskija · 2026-03-03T14:42:18Z

solr/core/src/test/org/apache/solr/handler/admin/api/NodeHealthAPITest.java

+  public void testCloudMode_RequireHealthyCoresReturnOkWhenAllCoresHealthy() {
+    CoreContainer coreContainer = cluster.getJettySolrRunner(0).getCoreContainer();
+
+    // requireHealthyCores=true should succeed on a node with no unhealthy cores


[-1] You haven't actually created any cores!!

Can you create a collection or something that'll cause this test to actually exercise the per-core logic currently in HealthcheckHandler?

I added something, and one thing is we may want to collapse our tests from HealthCheckHandlerTest at some point into this test case.

solr/core/src/test/org/apache/solr/handler/admin/api/NodeHealthAPITest.java

gerlowskija · 2026-03-03T14:53:15Z

solr/solr-ref-guide/modules/configuration-guide/pages/implicit-requesthandlers.adoc

-v2: `api/node/health` |{solr-javadocs}/core/org/apache/solr/handler/admin/HealthCheckHandler.html[HealthCheckHandler] |
+v2: `api/node/health` |v1: {solr-javadocs}/core/org/apache/solr/handler/admin/HealthCheckHandler.html[HealthCheckHandler]
+
+v2: {solr-javadocs}/core/org/apache/solr/handler/admin/api/NodeHealthAPI.html[NodeHealthAPI] |


[Q] Is it the implementation Javadocs we want to point people to here, or would the solr/api interface docs be more helpful?

Or more broadly - is there much value even in pointing to either Javadoc on the v2 side? HealthcheckHandler has a nice good blurb, but neither NodeHealthAPI nor NodeHealthApi have much of anything that's worth pointing a user at IMO...

Good question.... I think we need to decide what the pattern should be for these new apis... Where DO we want these apis to link to and be documented? I don't have a strong opinion, and honestlhy, if we punted this to a future JIRA I could live with that too.

@deprecated

…kHandler delegates to V2 - NodeHealthAPI now owns all business logic (cloud mode, legacy mode, isWithinGenerationLag, findUnhealthyCores) using strongly-typed NodeHealthResponse / NodeStatus throughout. - HealthCheckHandler becomes a thin V1 bridge: handleRequestBody() creates NodeHealthAPI(coreContainer).checkNodeHealth(...) and squashes the typed response into SolrQueryResponse. - findUnhealthyCores() moved to NodeHealthAPI as a public static util; HealthCheckHandler keeps a @deprecated delegation shim so existing callers continue to compile. - HealthCheckHandlerTest updated to call NodeHealthAPI.findUnhealthyCores() directly. - Utils.getReflectWriter() now serialises Enum values as their .name() string so that NodeStatus.OK round-trips as "OK" through NamedList/javabin, keeping HealthCheckHandlerTest assertions passing. - Fixed pre-existing bug in isWithinGenerationLag: condition was `generationDiff < maxGenerationLag` (wrong); corrected to `generationDiff > maxGenerationLag` with the return values adjusted so the method returns true=healthy / false=lagging-too-far. - Fixed missing slf4j log arguments in the negative-diff warning. Co-authored-by: epugh <22395+epugh@users.noreply.github.com>

epugh · 2026-03-10T00:28:11Z

Okay, at this point down to a decision on Enum impact, migrating all the business logic out of HealthCheckHandler, and Javadocs and then this may be good to go!

Chatted with @gerlowskija on phone, and we're going to take a stab at migrating business logic. Javadocs we won't do anything more creative than what we have for now. Forgot to ask about Enum.

Got a fix for handling the Enum comparisoin. I migrated the business logic, and removed a duplicate test in the process...

@gerlowskija I think this is ready for final review!

epugh · 2026-03-10T09:26:53Z

Oh, and the reason, based on spelunking, why we don't support maxGenerationLag in v2 is that it's a feature of the old leader/follower capability only. See TestHealthCheckHandlerLegacyMode.

I used claude for this regressoin test and I don't love how verbose they are. I tried a mock approach first and it was worse.

gerlowskija · 2026-03-17T13:10:05Z

why we don't support maxGenerationLag in v2 is that it's a feature of the old leader/follower capability only

I'm not sure I follow. Are you saying that you didn't port it to v2 because it's a standalone-only parameter @epugh ?

epugh · 2026-03-17T13:14:09Z

why we don't support maxGenerationLag in v2 is that it's a feature of the old leader/follower capability only

I'm not sure I follow. Are you saying that you didn't port it to v2 because it's a standalone-only parameter @epugh ?

And that it wasn't in the source V2 api either!

gerlowskija

Still some things that need sorted out IMO, but this is getting much closer!

Could you also expand a bit on the decision to not bring maxGenerationLag into the v2 API? You mentioned there'd been discussion of it, but I can't find it for whatever reason.

changelog/unreleased/SOLR-16458-migrate-node-health-api.yml

solr/core/src/java/org/apache/solr/handler/admin/api/NodeHealth.java

gerlowskija · 2026-03-17T15:04:51Z

solr/core/src/java/org/apache/solr/handler/admin/api/NodeHealth.java

+        // from the old index
+        if (generationDiff < 0) {
+          log.warn("core:[{}], generation lag:[{}] is negative.", core, generationDiff);
+        } else if (generationDiff > maxGenerationLag) {


[Q/-1] There's something funky going on in this conditional branch.

The boolean condition and the ret-value are opposite what they are on main. Which I think is OK - the double-reversal "cancels out" so to speak.

But shouldn't the log messages here change in some way? Were the initial log messages here inaccurate and by reversing the condition that triggers them you've "fixed" things? Or is it the opposite - were the initial log messages correct and are now misleading given the change in the triggering logic?

I didn't look deep, but the log messages here look like they make sense. so bug fix?

OK, on further thought:

I think you (and Copilot) are correct that the original else-if condition here was out-of-sync with the log message. With those conditions and ret-vals fixed, the log message looks "correct" to me.

If we're suggesting that this is an error case though, maybe the message should be a "warn" to make that clearer. But otherwise I think this is good 👍

I looked to see if there are any formatting patterns beyond the log.warn in messages and there aren't... can you be more specific? Otherwise I think this is similar to other logged warnings.

gerlowskija · 2026-03-17T15:06:58Z

solr/core/src/java/org/apache/solr/handler/admin/api/NodeHealth.java

+        // 2) Leader's index is wiped clean and the follower is still showing commit generation
+        // from the old index
+        if (generationDiff < 0) {
+          log.warn("core:[{}], generation lag:[{}] is negative.", core, generationDiff);


[Q/-1] The code on main returns false in this condition because the "catch-all" retval on L254 was "false".

Was that an intentional change? Or is this a mistake?

I checked and copilot highlghted "Corrected a pre-existing bug in isWithinGenerationLag: the condition was generationDiff < maxGenerationLag (inverted); corrected to > maxGenerationLag with correct return values (true = healthy, false = lagging). Also fixed missing slf4j log arguments."

[-1] Your response seems to be talking about the codeblock that starts on L217 a line or two below this one, which compares generationDiff and maxGenerationLag. Did you maybe leave this reply in the wrong place?

This codeblock is checking whether generationDiff is negative. So your reply above and the Copilot rationale aren't really relevant AFAICT?

solr/core/src/java/org/apache/solr/handler/admin/HealthCheckHandler.java

gerlowskija · 2026-03-17T15:25:38Z

solr/core/src/test/org/apache/solr/handler/admin/api/NodeHealthSolrCloudTest.java

+  @Test
+  public void testCloudMode_UnhealthyWhenZkClientClosed() throws Exception {
+    // Use a fresh node so closing its ZK client does not break the primary cluster node
+    JettySolrRunner newJetty = cluster.startJettySolrRunner();


[-1] I bet @dsmiley would know for sure, but...

AFAIK there's nothing in cluster.startJettySolrRunner() that ensures the new SolrCloud node is connected to ZK, a part of live_nodes, etc. when it returns. For this reason many callers of cluster.startJettySolrRunner() also call cluster.waitForAllNodes() or cluster.waitForNode right after.

So this code has a race condition - if the new node is slow to connect to ZK the healthcheck API call here will (correctly!) fail.

Assuming my understanding here is correct (which it may not be - really hoping David corrects me) - I wonder if there's anything we could do to catch this with a linting tool of some kind....

Isn't tehre another method that sets up a cluster that could have the correct waitForAllNodes? So we don't get surprised?

And yes, we need liniting or more rules in AGents to capture these things.

I'm asking copilot to look overall at our code base... and fixing this specfiic case.

gerlowskija · 2026-03-17T15:26:09Z

solr/core/src/test/org/apache/solr/handler/admin/api/NodeHealthSolrCloudTest.java

+   */
+  @Test
+  public void testCloudMode_NotInLiveNodes_ThrowsServiceUnavailable() throws Exception {
+    JettySolrRunner newJetty = cluster.startJettySolrRunner();


[-1] Ditto my comment on L77 above about starting a new SolrCloud node but not waiting to ensure it joins the cluster.

gerlowskija · 2026-03-17T15:28:31Z

solr/core/src/test/org/apache/solr/handler/admin/api/NodeHealthTest.java

+
+    assertNotNull(response);
+    assertEquals(OK, response.status);
+    assertTrue(


[0] Small nit, but this won't actually tell a developer what the 'message' field actually was.

I typically use Hamcrest matchers in these scenarios, as they have really nice error messages on failure by default. e.g.

assertThat(response.message, containsString("maxGenerationLag isn't specified"));

you need to unleash claude on making this chagne once and for all across our code base ;-). It'sj just tokens!

gerlowskija · 2026-03-17T15:30:55Z

solr/core/src/test/org/apache/solr/handler/admin/HealthCheckHandlerTest.java

+
+        assertEquals("Expected 503 SERVICE_UNAVAILABLE", 503, response.statusCode());
+        assertTrue(
+            "v1 error response body must contain status=FAILURE so body-inspecting clients get"


[0] Again, Hamcrest matchers would make this a bunch cleaner:

assertThat(response.body, containsString("FAILURE"));

gerlowskija · 2026-03-17T15:32:41Z

solr/solrj/src/java/org/apache/solr/common/util/Utils.java

+    // Enums serialized as their declared name so that javabin/NamedList consumers
+    // (e.g. HealthCheckHandlerTest comparing against CommonParams.OK == "OK") see
+    // a plain string rather than "pkg.EnumClass:NAME".
+    if (o instanceof Enum) {


[0] You can avoid the cast by using some a newer bit of Java syntax that declares an already-cast variable:

if (o instanceof Enum e) { return e.name(); } ...

Tha is nicer!

gerlowskija · 2026-03-17T15:38:44Z

And that it wasn't in the source V2 api either!

Ah - unless you can find specific discussion of it in JIRA or on the original PR, I'd consider that more of a bug than something we want to replicate. One of the huge shortcomings of the original v2 implementation is that nothing ever kept the v1 APIs in sync with their v2 counterparts. So it's extremely common to find cases where:

A v2 API was added back in 2016 or so.
Years later the v1 API evolved, got new functionality, gained some new parameters, etc.
The v2 API wasn't updated at the time and fell behind.

This dynamic is another huge argument for v2-ifying the actual implementation logic for these APIs. When the v1 code is just a shim around the v2 code, there's no way for the "v2" endpoint to fall behind the way we've seen in the past.

…e-health-api

epugh · 2026-03-19T10:45:02Z

@gerlowskija I have responded/fixed everything EXCEPT the generation lag..

Do you want me to resolve conversations/comments as I fix them, or push up the fix and let you resolve them?

@QueryParam

- NodeHealthApi: add @QueryParam("maxGenerationLag") Integer maxGenerationLag with @parameter description to healthcheck() - NodeHealth: update healthcheck() to accept and forward maxGenerationLag; remove now-redundant checkNodeHealth() bridge method - HealthCheckHandler: call healthcheck() directly (no more checkNodeHealth()) - NodeApi (generated SolrJ): regenerated - Healthcheck gains setMaxGenerationLag() setter and includes the param in getParams() - NodeHealthStandaloneTest: remove FIXME; test negative-maxGenerationLag via the real V2 HTTP path using NodeApi.Healthcheck.setMaxGenerationLag(-1) Co-authored-by: epugh <22395+epugh@users.noreply.github.com>

- Add new "Monitoring Follower Replication Lag" section to user-managed-index-replication.adoc with V1+V2 API examples, example responses (success and failure), and a warning about using maxGenerationLag=0 in production. - Update implicit-requesthandlers.adoc Health entry: remove the inaccurate "available only in SolrCloud mode" qualifier; add a concise description of both SolrCloud params (requireHealthyCores) and legacy-mode params (maxGenerationLag) with a cross-reference to the new monitoring section. Co-authored-by: epugh <22395+epugh@users.noreply.github.com>

epugh · 2026-03-19T11:37:05Z

And we have generation lag! Plus some actual docs about it since it was a completely NEW parameter to me.

…lr into copilot/migrate-node-health-api

gerlowskija · 2026-03-19T14:38:29Z

Do you want me to resolve conversations/comments as I fix them, or push up the fix and let you resolve them?

I'm 👍 with you clicking "Resolve Conversation". I trust you're not doing it on stuff that's controversial or whatever, and it saves me from a bunch of additional reading each time I open this PR back up.

(When I'm on the other side of things and doing the editing it also makes for a nice little built-in "To Do" list too...not sure if others users it that way or not)

Anyway, re-reviewing now...

gerlowskija

This is super close - I think there's just one last thing that needs addressed in NodeHealth.java. Feel free to ignore any of my comments that aren't [-1]

gerlowskija · 2026-03-19T14:42:40Z

changelog/unreleased/SOLR-16458-migrate-node-health-api.yml

 type: added
 authors:
  - name: Eric Pugh
+  - name: Jason Gerlowski


[Q] (General question; not PR specific)

Is it our convention to add reviewers here as well?

I'm all for that but it'd be great to document in dev-docs/changelog.adoc if that's a convention we'd like to cement!

i added you because you went beyond review, I mean, this PR chagned a lot....! Just causeyou didn't type characters doens't mean you didn't have a lot of input! I think you authored this as much as I did.

solr/core/src/test/org/apache/solr/handler/admin/api/NodeHealthTest.java

gerlowskija · 2026-03-19T14:52:53Z

solr/core/src/test/org/apache/solr/handler/admin/api/NodeHealthTest.java


 public class NodeHealthTest extends SolrCloudTestCase {

-  /**


[-0] I love that this test is now SolrCloud only, but should it's name be changed to indicate that. And maybe it should have Javadocs that link to its standalone counterpart.

e.g.

/** * Tests for the node-health API, on SolrCloud clusters * * @see NodeHealthStandaloneTest */ public class NodeHealthSolrCloudTest extends SolrCloudTestCase {

solr/solr-ref-guide/modules/deployment-guide/pages/user-managed-index-replication.adoc

solr/api/src/java/org/apache/solr/client/api/endpoint/NodeHealthApi.java

gerlowskija · 2026-03-19T15:10:42Z

solr/core/src/java/org/apache/solr/handler/admin/api/NodeHealth.java

+        // 2) Leader's index is wiped clean and the follower is still showing commit generation
+        // from the old index
+        if (generationDiff < 0) {
+          log.warn("core:[{}], generation lag:[{}] is negative.", core, generationDiff);


[-1] Your response seems to be talking about the codeblock that starts on L217 a line or two below this one, which compares generationDiff and maxGenerationLag. Did you maybe leave this reply in the wrong place?

This codeblock is checking whether generationDiff is negative. So your reply above and the Copilot rationale aren't really relevant AFAICT?

gerlowskija · 2026-03-19T15:18:54Z

solr/core/src/java/org/apache/solr/handler/admin/api/NodeHealth.java

+        // from the old index
+        if (generationDiff < 0) {
+          log.warn("core:[{}], generation lag:[{}] is negative.", core, generationDiff);
+        } else if (generationDiff > maxGenerationLag) {


OK, on further thought:

I think you (and Copilot) are correct that the original else-if condition here was out-of-sync with the log message. With those conditions and ret-vals fixed, the log message looks "correct" to me.

If we're suggesting that this is an error case though, maybe the message should be a "warn" to make that clearer. But otherwise I think this is good 👍

Copilot AI and others added 4 commits February 22, 2026 12:52

Initial plan

0585c2a

Migrate NodeHealthAPI from @endpoint to JAX-RS annotations

4aa9e8b

Co-authored-by: epugh <22395+epugh@users.noreply.github.com>

Add NodeHealthAPITest2: integration tests without Mockito mocks

8e2ccd5

Co-authored-by: epugh <22395+epugh@users.noreply.github.com>

Restore logic to HealthCheckHandler, simplify NodeHealthAPI, update r…

a50f682

…ef guide Co-authored-by: epugh <22395+epugh@users.noreply.github.com>

epugh mentioned this pull request Feb 28, 2026

Migrate NodeHealthAPI to JAX-RS, flip delegation so V2 owns logic, add replication lag monitoring docs epugh/solr#22

Draft

github-actions bot added documentation Improvements or additions to documentation tests cat:api labels Feb 28, 2026

epugh mentioned this pull request Feb 28, 2026

SOLR-16458: Convert /api/node/system to JAX-RS #4078

Merged

8 tasks

epugh marked this pull request as ready for review February 28, 2026 13:20

epugh requested review from gerlowskija and janhoy February 28, 2026 13:20

restore docs

b8159ab

epugh added the no-changelog label Feb 28, 2026

Copilot AI mentioned this pull request Feb 28, 2026

Migrate RenameCoreAPI from homegrown @EndPoint/@Command to JAX-RS; use SolrJettyTestRule in tests epugh/solr#24

Closed

lint

01696e3

dsmiley reviewed Feb 28, 2026

View reviewed changes

solr/api/src/java/org/apache/solr/client/api/model/NodeHealthResponse.java Outdated Show resolved Hide resolved

solr/core/src/java/org/apache/solr/handler/admin/HealthCheckHandler.java Outdated Show resolved Hide resolved

epugh added 2 commits March 1, 2026 12:58

Keep the non mock version

dac4e14

Responding to feedback

ec8252a

lint

b592322

epugh changed the title ~~Migrate NodeHealthAPI from homegrown @EndPoint to JAX-RS; add ref guide link~~ Migrate NodeHealthAPI from homegrown @EndPoint to JAX-RS Mar 2, 2026

epugh removed the no-changelog label Mar 3, 2026

add changelog

ca88d6e

epugh changed the title ~~Migrate NodeHealthAPI from homegrown @EndPoint to JAX-RS~~ SOLR-16458: Migrate NodeHealthAPI from homegrown @EndPoint to JAX-RS Mar 3, 2026

gerlowskija requested changes Mar 3, 2026

View reviewed changes

Copilot AI and others added 2 commits March 9, 2026 19:24

Migrate business logic into NodeHealthAPI, and fix enum issue

71feb02

github-actions bot added the client:solrj label Mar 10, 2026

epugh added 2 commits March 11, 2026 07:07

Follow the existing naming pattern.

2a81e9e

Add test for failure cases.

fc6ee9e

I used claude for this regressoin test and I don't love how verbose they are. I tried a mock approach first and it was worse.

gerlowskija requested changes Mar 17, 2026

View reviewed changes

epugh added 8 commits March 18, 2026 08:23

Merge remote-tracking branch 'upstream/main' into copilot/migrate-nod…

1b7c709

…e-health-api

Nicer coding style

e9e6c02

Nicer assert style.

3f5e8ab

Updates from merging latest code in.

4a5fb4d

use assertThat

ee3cc2a

Migrate to hamcrest, and use standalone not legacy terms.

bec1201

Split up standalone versus cloud mode tests.

aecb703

clearer changelog

3b48bdd

Copilot AI and others added 2 commits March 19, 2026 11:04

epugh added 2 commits March 19, 2026 08:21

better name

df5c6f9

Merge branch 'copilot/migrate-node-health-api' of github.com:epugh/so…

3165c6e

…lr into copilot/migrate-node-health-api

gerlowskija requested changes Mar 19, 2026

View reviewed changes

epugh added 2 commits March 19, 2026 15:18

Responding to feedback

fc7c7cf

Post discussion with jason...

71a778d

epugh merged commit 5d2eb05 into apache:main Mar 21, 2026
3 of 5 checks passed

Conversation

epugh commented Feb 28, 2026

Design

Key changes

Uh oh!

epugh commented Feb 28, 2026

Uh oh!

epugh commented Feb 28, 2026

Uh oh!

Uh oh!

Uh oh!

epugh commented Mar 1, 2026

Uh oh!

gerlowskija commented Mar 3, 2026

Uh oh!

epugh commented Mar 3, 2026

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!

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epugh commented Mar 10, 2026

Uh oh!

epugh commented Mar 10, 2026

Uh oh!

gerlowskija commented Mar 17, 2026

Uh oh!

epugh commented Mar 17, 2026

Uh oh!

gerlowskija left a comment

Choose a reason for hiding this comment

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!