SOLR-18130: rename parameter "zkHost" to "solrCloud" in "solrj-streaming" by vyatkinv · Pull Request #4320 · apache/solr

vyatkinv · 2026-04-22T11:14:55Z

https://issues.apache.org/jira/browse/SOLR-18130

Description

This PR updates the solrj-streaming module by replacing all usages of zkHost with solrCloud to enable support for HTTP-based quorum configurations.

Solution

Parameters, fields and variables in solrj-streaming, named as zkHost renamed to solrCloud
For backward compatibility, specifying zkHost is still supported.
A shared method has been introduced in an abstract class to resolve the effective solrCloud value using a priority-based approach (e.g., explicit parameter → legacy zkHost → default Zookeeper host).

Tests

To Be Done

Checklist

Please review the following and check all that apply:

I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
I have created a Jira issue and added the issue ID to my pull request title.
I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
I have developed this patch against the main branch.
I have run ./gradlew check.
I have added tests for my changes.
I have added documentation for the Reference Guide
I have added a changelog entry for my change

Planned follow-ups:

Perform more thorough testing of solrj-streaming with both Zookeeper-based and HTTP-based quorum configurations
Add unit tests for HTTP quorum support
Review and improve error messages and java-doc, where zookeeper still mentioned
Add documentation and changelog entry

Open Questions / Discussion Points

I would appreciate feedback on the following topics (also noted as TODOs in the code):

1. Mandatory solrCloud parameter

I made solrCloud required in all stream handlers (an error is thrown if it cannot be resolved from parameters or the default Zookeeper host).
This caused two tests to fail:

StreamExpressionTest#testCloudSolrStream
StreamExpressionTest#testStatsStream

These tests did not provide any valid host.
I fixed them by adding .withDefaultZkHost(cluster.getZkServer().getZkAddress())

Question:

Is this a test issue or a flaw in the implementation?
Can such a situation occur in real-world usage?

2. toExpression behavior and backward compatibility

Currently, toExpression reconstructs the expression and always includes solrCloud, even if the user originally provided the legacy zkHost parameter.
As a result, a user who runs an expression with zkHost and then calls explain() will see solrCloud in the output.

Question:

Should the original parameter name (zkHost) be preserved?
Or is it acceptable to normalize everything to solrCloud?

3. Potential issue with gather parameter
In:
org/apache/solr/client/solrj/io/graph/GatherNodesStream.java:392
there is the following line:
expression.addParameter(new StreamExpressionNamedParameter("gather", solrCloud));

Question:

Is this a bug?
Or is solrCloud (previously zkHost) actually intended to be passed as gather?

UPDATE: I looked into the context more deeply and yes, it looks like this is a defect that affects explain(). I fixed it as part of my pull request.

4. Inconsistent parameter handling
Some stream handlers use Map<String, String> for parameters, while others use ModifiableSolrParams.

Question:

Would it make sense to standardize on a single approach?

5. ScoreNodesStream limitation
ScoreNodesStream can only obtain zkHost / solrCloud via: factory.getDefaultZkHost();

Question:

Should this be improved as part of this PR?
Or would it be better to handle it in a separate issue?

…ing" module

epugh · 2026-04-22T16:35:36Z

Shouldn't solrCloud be connectionString? I was hoping down the road we could put more into the connection string like username password or other details that are needed....

…eams

vyatkinv · 2026-04-23T03:50:46Z

Shouldn't solrCloud be connectionString? I was hoping down the road we could put more into the connection string like username password or other details that are needed....

@dsmiley previously suggested naming this parameter solrCloud in the jira ticket comments. However, it looks like there might be some disagreement here, so it would be good to reach a consensus before finalizing the name.

epugh · 2026-04-23T12:00:36Z

Shouldn't solrCloud be connectionString? I was hoping down the road we could put more into the connection string like username password or other details that are needed....

@dsmiley previously suggested naming this parameter solrCloud in the jira ticket comments. However, it looks like there might be some disagreement here, so it would be good to reach a consensus before finalizing the name.

Agreed... I believe the intent is to specify how you connect to your running Solr? In the first PR I believe it was connectionString which makes sense as "hey, I'm going to have to parse this thing, and it tells me how to connect". @dsmiley ?

dsmiley

Great work here! Clearly this was a bit more involved than a rename ;-)

"connectionString" is somewhat long and it's ambiguous as to what we're even connecting to. But it's not bad. How about "solrCloudString"? If you don't like that, I'll capitulate and be satisfied with "connectionString".

Incorporating auth is out-of-scope but I'll say now that I'm suspicious that it makes sense to embed secret credentials into this. A conversation for another time.

I imagine there should be some ref-guide updates on this in addition to major-changes-in-solr-10.adoc.

I can see the potential of a follow-on issue to update CLIUtils.getZkHost (and thus CLI commands that call it) to instead resolve a SolrCloud connection string that is not necessarily ZK.

Answers to the PR questions:

It's a test issue -- good catch. Glad you made resolving this mandatory. I wouldn't call this "mandatory SolrCloud parameter" since the param can be blank when it's used inside Solr, defaulting to the server's connection.
Normalize; do not round-trip with "zkHost".
IMO SolrParams should be used for "parameters" like this, not Map. Perhaps too much scope creep here but I leave that to you.
Let's not add support for that to ScoreNodes now, albeit a single comment where we initialize it would be nice. Like "for now limited to the current cluster but we could expand support if needed".

I suggest that you change StreamFactory to not mention "ZK" whatsoever, instead using the name we choose (e.g. getDefaultCloudString). For backwards-compatibility, however, the older method names should exist as deprecated.

dsmiley · 2026-04-24T02:15:12Z

@@ -0,0 +1,7 @@
+title: Parameter 'zkHost' renamed to 'solrCloud' in solrj-streaming. Parameter 'zkHost' is still supported.


Useful / fine but omits a bigger feature/point in this PR: this parameter now supports HTTP based SolrCloud connection strings (ZK access no longer required).

dsmiley · 2026-04-24T02:22:06Z

-              collectionName));
-    }
+    ModifiableSolrParams params =
+        getModifiableSolrParamsWithExclusions(


ModifiableSolrParams is a specific impl of SolrParams. I don't think this method name should contain the word "Modifiable"; it's a detail.

dsmiley · 2026-04-24T02:25:01Z


  public ShortestPathStream(
-      String zkHost,
+      String solrCloud,


Can we use that nice record you made previously for the connection string instead of String? To be used not just right here but really everywhere in this PR that needs to refer to the connection. It would be so nice to have a real type vs String which is used for anything and everything, defeating the typed nature of Java.
If not, fine.

String can be replaced with record in private methods, but I'm not sure about public constructors. Even if they are not used within the project, they can still be used by consumers. We can declare them deprecated and introduce new ones with Record

What ought to be deprecated vs okay to change whenever is often a gray area taking some experience with the project. Even though I haven't personally used the code being changed in this way, I suspect that the only constructor that matters on these things is the StreamExpression expression, StreamFactory factory one. Notice that the other is only used in tests.

dsmiley · 2026-04-24T02:29:22Z

+    // we don't
    // need to count it twice


reflow newline

dsmiley · 2026-04-24T02:31:27Z

+    // don't
    // need to count it twice


reflow newline

dsmiley · 2026-04-24T02:58:58Z

    return shards;
  }

+  public static String getSolrCloud(


So I know I suggested calling the param "solrCloud" because in context to where a user types it (a streaming expression string), it seems a reasonable choice. But at a code level like here and all the var names, I find it... not so good. getCloudConnectionString would be better IMO and maybe used the record type you made.

BTW I love this refactoring overall; it cuts down on repeated code.

done
renamed to buildSolrConnection

dsmiley · 2026-04-24T02:59:55Z

+    return solrCloud;
+  }
+
+  public static ModifiableSolrParams getModifiableSolrParamsWithExclusions(


I suggest the name buildSolrParams or buildSolrParamsExcept.
"Modifiable" is overly specific to the SolrParams type.
"get" is overused in java... suggests we retrieve something when in fact we are creating something here.
Also IMO the varargs should be a Set that the caller can easily pass via Set.of

done
renamed to
buildSolrParamsExcept

dsmiley · 2026-04-24T03:07:25Z

+    return mParams;
+  }
+
+  public static Map<String, String> getMapWithExclusions(


if the above method uses MapSolrParams instead of ModifiableSolrParams, then we don't even need this version here since the (few?) callers using it can call MapSolrParams.getMap().

ModifiableSolrParams.getMap() returns Map<String, String[]> but we needs Map<String, String>

That's why I asked if it was possible to convert all streams to ModifiableSolrParams :)

but I'll think about it some more, maybe I can use generics or a common interface to make a single universal method

I specifically referred to MapSolrParams.getMap() which returns Map<String, String>

It's also okay to leave both... maybe marking one as deprecated to signify an older approach.

done
I reworked streams that were using getMapWithExclusions to use SolrParams, or ModifiableSolrParams where a mutable implementation is required.

dsmiley · 2026-04-24T03:08:24Z


  private void init(
-      String collectionName, TupleStream tupleSource, String zkHost, int updateBatchSize) {
+      String collectionName, TupleStream tupleSource, String solrCloud, int updateBatchSize) {


param order

epugh · 2026-04-30T14:42:47Z

Hi all... So I'm following up after @dsmiley pinged me (thanks!)... What I am excited about this is the opportunity to make it simpler for non Solr experts to access solr. I don't think that you should need to know if it's solrCloud or standalone or zk that you are using, it's just a "connection string". Yes, every connection string has rules of formatting... I would like a name like solrConnection or solrConnString but not something that is as specific as "solrCloudConnection" that ties us to a specific mode of Solr. I know that "Streaming Expressions" is a solr cloud specific feature. However, from a user perspective, they may not know that, or care.

Someday I hpoe to see Streaming Expressions pushed more towards our Data Scientist / ML user base, and they don't care about Cloud versus non Cloud mode, and also don't care about zkHost... So, having a property that speaks to their concern "how do I connect" is perfect. Could we have a property like solr or connection?

dsmiley · 2026-04-30T17:00:29Z

+1 to "solrConnection"

Could we have a property like solr or connection

huh; you just agreed to "solrConnection"?

epugh · 2026-05-01T11:48:07Z

I was just wondering if in the context of a stream expression if saying "connection" was enough. I like "solrConnection" too. We might look at other connections and see what they are named...

dsmiley · 2026-05-01T13:43:59Z

Then lets move forward @vyatkinv with "solrConnection" throughout. If at the last minute Eric gets us to change our minds again, we shouldn't need to subsequently change the vast majority of this PR since "solrConnection" is a perfectly fine parameter & field & local-var name in all places we have such.

…g> by SolrParams in streams, which used it

vyatkinv · 2026-05-02T16:11:18Z

I’ve addressed most of the review comments. Summary of changes in the latest commits:

Renamed solrCloud parameter to solrConnection.
Switched Streams to use CloudSolrClientConnection instead of a raw string.
To do this, I broke backward compatibility for constructors that accepted parameters directly. I believe this is acceptable since end users are not expected to instantiate stream implementations directly—they typically pass string expressions into StreamFactory. Most of these constructors are used internally, in tests, or not used at all.
If needed, I can restore the old constructors as @Deprecated and delegate them to the new ones based on CloudSolrClientConnection.
Fixed minor issues related to formatting and parameter ordering.
Renamed getSolrConnection to buildSolrConnection.
Added a new method to CloudSolrClient.Builder so internal Solr code can use the typed builder, while keeping the string-based API for end users.
For the same reason, I replaced the string-based getCloudSolrClient with a typed variant.
One concern: currently zkHost can accept HTTP URLs.
It seems more consistent if:
- zkHost only allows ZooKeeper connection strings,
- Solr URLs only allow HTTP(S),
- and the new solrConnection supports both.
  Should we add validation in StreamTool, the JDBC driver, and buildSolrConnection() to enforce that zkHost is strictly ZooKeeper? And allow both formats only via the new parameter?
Renamed parameter-building method to buildSolrParamsExcept and refactored it to remove the Map<String, String> variant, reusing the unified implementation.

As follow-up work (either separate issue or PR), I suggest:
a) adding support for HTTP quorum in the StreamTool CLI
b) adding support for HTTP quorum in the JDBC driver

PS: Documentation and new tests are not added yet.

epugh · 2026-05-02T17:38:39Z

          .get();

+  public static final Option SOLR_CONNECTION_OPTION =
+      Option.builder("q")


"q"? Interesting... I don't know that I have a opinion one way or the other... Could SOLR_CONNECTION_OPTION just be SOLR_URL_OPTION? I.e do we need another property or can we just use SOLR_URL_OPTION instead? And extend what it takes.

I didn’t add an implementation for parse this option. It might be better to remove it from here entirely and implement it in a separate PR.

Also, q is just a shorthand for “quorum”.

I initially planned to implement this option in this PR, but later realized it is not trivial, so I dropped the idea for now and simply forgot to remove it.

Ahh... That makes sense, yeah, let's remove it from this PR

epugh · 2026-05-02T17:40:43Z

@@ -70,7 +71,7 @@ public class ShortestPathStream extends TupleStream implements Expressible {
  private String toField;
  private int joinBatchSize;
  private int maxDepth;
-  private String solrCloud;
+  private CloudSolrClient.CloudSolrClientConnection solrConnection;


Maybe just a tiny bit odd that this property is defined in a specic CloudSolrClient. Probably jsut me!

Maybe you mean you don't like that CloudSolrClientConnection is an inner-class? (technically a record actually) It was created weeks ago to represent a connection to SolrCloud for the benefit of CloudSolrClient... so.... it's here. If we think we might use it in other contexts, it could move.

I'm already disliking the word "Client" in that name.

epugh

This is really looking great. I think you can mark it "not draft" mode ;-)

epugh · 2026-05-02T17:42:50Z

@@ -170,8 +171,8 @@ public StreamExpression toExpression(StreamFactory factory) throws IOException {
      }
    }

-    // solrCloud
-    expression.addParameter(new StreamExpressionNamedParameter("solrCloud", solrCloud));


So we don't expose solrCloud as a property in our streaming expressions? Checking https://solr.apache.org/guide/solr/latest/query-guide/stream-source-reference.html#search-parameters it looks just fine!

epugh · 2026-05-02T17:44:03Z

@@ -56,9 +57,8 @@
 */
 public class RandomStream extends TupleStream implements Expressible {

-  private String solrCloud;
-  // TODO: replace all Map<String, String> in stream handlers by ModifiableSolrParams ?


nice clean up!

epugh · 2026-05-02T17:45:45Z

-          chroot != null && connectionString.endsWith(chroot)
-              ? connectionString.substring(0, connectionString.length() - chroot.length())
-              : connectionString;
+    if (solrConnection.isZk()) {


I don't know that I love the short cut isZK versus isZooKeeper (or however we case it? my just be my style.

I guess it's fine.. it reads pretty easy.

Have we already published and released something with CloudSolrClientConnection? If not, we'll change it.

10.1 hasn't shipped, so it can be changed easily now

done. renamed to isZookeeper

epugh · 2026-05-02T17:48:08Z

Should we add validation in StreamTool, the JDBC driver, and buildSolrConnection() to enforce that zkHost is strictly ZooKeeper? And allow both formats only via the new parameter?

I think that is a great idea! Please do...

epugh · 2026-05-02T17:49:33Z

As follow-up work (either separate issue or PR), I suggest: a) adding support for HTTP quorum in the StreamTool CLI b) adding support for HTTP quorum in the JDBC driver

PS: Documentation and new tests are not added yet.

From my perspective Docs and new tests NEED to be part of this PR. I think adding the quorum stuff can be part of this PR or a follow depending on your approach...

dsmiley

Wow this has become an even bigger PR. Great work here!

dsmiley · 2026-05-03T04:01:11Z

@@ -86,7 +86,8 @@ public boolean isClosed() {
  @Override
  protected Map<String, Table> getTableMap() {
    String zk = this.properties.getProperty("zk");


it's reasonably in scope to switch this out too... still supporting "zk" for back-compat.

dsmiley · 2026-05-03T04:03:48Z

      }

-      TupleStream cloudSolrStream = new CloudSolrStream(streamZkHost, collection, params);
+      var solrConnection = CloudSolrClient.CloudSolrClientConnection.parse(streamZkHost);


it's reasonably in-scope to update cross-collection join queries to take a "solrConnection" string from the join params, keeping zkHost for back-compat fallback.

dsmiley · 2026-05-03T04:14:08Z

@@ -295,7 +297,7 @@ private Metric getMetric(Pair<String, String> metricPair) {
  }

  private TupleStream handleSelect(
-      String zk,
+      CloudSolrClient.CloudSolrClientConnection solrClientConnection,


minor: rename to solrConnection

dsmiley · 2026-05-03T04:34:41Z

-    // we don't
-    // need to count it twice
+    // Validate there are no unknown parameters - solrConnection/zkHost and alias are
+    // namedParameter,


dsmiley · 2026-05-03T04:42:57Z

@@ -381,14 +392,14 @@ protected static class FeaturesSelectionCall implements Callable<NamedList<?>> {
    private final String baseUrl;
    private final String outcome;
    private final String field;
-    private final Map<String, String> paramsMap;


In many places like here you declare a param or field with the type ModifiableSolrParams but that's too specific -- SolrParams should be used.

dsmiley · 2026-05-03T04:45:49Z

@@ -411,7 +422,7 @@ public NamedList<?> call() throws Exception {
      params.add(DISTRIB, "false");
      params.add("fq", "{!igain}");

-      for (Map.Entry<String, String> entry : paramsMap.entrySet()) {
+      for (Map.Entry<String, String[]> entry : paramsMap) {
        params.add(entry.getKey(), entry.getValue());
      }


the switch to SolrParams instead of a Map means we can simply call params.add(paramsMap) in here and some other places in this big PR

dsmiley · 2026-05-03T04:54:19Z

+    for (Entry<String, String[]> param : props) {
+      for (String paramValue : param.getValue()) {
+        expression.addParameter(new StreamExpressionNamedParameter(param.getKey(), paramValue));
+      }
    }


I've seen this enough times that think there ought to be a utility method, maybe on a base class, that does this. up to you.

done. added method addParameters to StreamExpression

dsmiley · 2026-05-03T05:00:13Z

-      ModifiableSolrParams params = new ModifiableSolrParams();
+      ModifiableSolrParams queryRequestParams = new ModifiableSolrParams();


I recommend SolrQuery here, and it has some convenience methods for some of these well known params too.

dsmiley · 2026-05-03T05:07:25Z

@@ -76,36 +76,35 @@ public void setDefaultZKHost(String zkHost) {
    }
  }

-  public synchronized CloudSolrClient getCloudSolrClient(String connectionString) {
+  public synchronized CloudSolrClient getCloudSolrClient(


I think we'll need a deprecated overload here for the previous signature

… ZooKeeper connection strings

vyatkinv · 2026-05-03T07:54:28Z

I noticed another issue while writing tests: SolrClientCache stores both HTTP clients and Cloud clients in the same cache. This can lead to problems — for example, if a client was previously created and cached as a plain HTTP client for a given base URL, attempting to retrieve a Cloud client for the same URL later results in a ClassCastException.

To address this, I split the cache into separate stores for HTTP and Cloud clients.

…arser

vyatkinv · 2026-05-03T08:03:06Z

I’ve addressed several minor review comments and updated the streaming documentation.

In addition, I added validation to ensure that the legacy zkHost parameter is strictly a ZooKeeper connection string.

Next steps (planned shortly):

Add tests for the solrConnection parameter
Extend support for solrConnection in the SQL module and StreamingTool CLI
Document these changes in major-changes-in-solr-10.adoc, noting that these modules will support both ZooKeeper- and HTTP(S)-based connections

One open question is the SQL module. Supporting HTTP(S) connections there may be less straightforward, since a connection string like:
jdbc:solr://http://solr1:8080/solr,http://solr2:8080/solr?collection=foo
looks somewhat awkward and potentially problematic.

I’d appreciate any suggestions on the best way to approach this.

github-actions Bot added client:solrj tests labels Apr 22, 2026

vyatkinv marked this pull request as draft April 22, 2026 11:15

vyatkinv changed the title ~~[WIP] SOLR-18130: rename parameter "zkHost" to "solrCloud" in "solrj-streaming"~~ WIP: SOLR-18130: rename parameter "zkHost" to "solrCloud" in "solrj-streaming" Apr 22, 2026

vyatkinv changed the title ~~WIP: SOLR-18130: rename parameter "zkHost" to "solrCloud" in "solrj-streaming"~~ SOLR-18130: rename parameter "zkHost" to "solrCloud" in "solrj-streaming" Apr 22, 2026

SOLR-18130: rename parameter "zkHost" to "solrCloud" in "solrj-stream…

c877f2a

…ing" module

vyatkinv force-pushed the SOLR-18130-solrj-streaming-solr-cloud-parameter branch from 27f4ae5 to c877f2a Compare April 22, 2026 13:36

vyatkinv added 2 commits April 23, 2026 10:48

SOLR-18130: add getMapWithExclusions, fix errors, refactored lost str…

7fa9646

…eams

SOLR-18130: add changelog

b374cb6

dsmiley reviewed Apr 24, 2026

View reviewed changes

vyatkinv added 5 commits May 2, 2026 18:57

Merge branch 'main' into SOLR-18130-solrj-streaming-solr-cloud-parameter

46a7eea

SOLR-18130: rename solrCloud to solrConnection

8e2e63a

SOLR-18130: reorder params in init()

01c350e

SOLR-18130: using a typed solrConnection instead of a string one

2bd00e1

SOLR-18130: rework of buildSolrParamsExcept, replace Map<String,Strin…

b4cd769

…g> by SolrParams in streams, which used it

github-actions Bot added module:sql cat:search cat:cli labels May 2, 2026

vyatkinv added 4 commits May 2, 2026 23:18

SOLR-18130: Fix changelog entry

43ad271

SOLR-18130: fix reflow

238e487

SOLR-18130: fix param order

a4ff28c

SOLR-18130: replace varargs by set in buildSolrParamsExcept

c4f5adc

SOLR-18130: unify variable name

6d2af2b

epugh reviewed May 2, 2026

View reviewed changes

epugh approved these changes May 2, 2026

View reviewed changes

SOLR-18130: revert CommonCLIOptions changes

e189537

dsmiley reviewed May 3, 2026

View reviewed changes

dsmiley marked this pull request as ready for review May 3, 2026 05:11

vyatkinv added 4 commits May 3, 2026 14:01

SOLR-18130: fix code review issues

cd40a9e

SOLR-18130: Add validation to ensure 'zk' and 'zkHost' properties are…

c5c23bb

… ZooKeeper connection strings

SOLR-18130: Add solrConnection to streaming documentation

2a92901

SOLR-18130: remove resolved TODO

16fc2ea

github-actions Bot added the documentation Improvements or additions to documentation label May 3, 2026

SOLR-18130: add support for 'solrConnection' in CrossCollectionJoinQP…

a52417e

…arser

		@@ -0,0 +1,7 @@
		title: Parameter 'zkHost' renamed to 'solrCloud' in solrj-streaming. Parameter 'zkHost' is still supported.

		ModifiableSolrParams params = new ModifiableSolrParams();
		ModifiableSolrParams queryRequestParams = new ModifiableSolrParams();

Conversation

vyatkinv commented Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Solution

Tests

Checklist

Planned follow-ups:

Open Questions / Discussion Points

Uh oh!

epugh commented Apr 22, 2026

Uh oh!

vyatkinv commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

epugh commented Apr 23, 2026

Uh oh!

dsmiley 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!

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!

vyatkinv May 2, 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!

vyatkinv Apr 24, 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!

Uh oh!

epugh commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dsmiley commented Apr 30, 2026

Uh oh!

epugh commented May 1, 2026

Uh oh!

dsmiley commented May 1, 2026

Uh oh!

vyatkinv commented Apr 22, 2026 •

edited

Loading

vyatkinv commented Apr 23, 2026 •

edited

Loading

vyatkinv May 2, 2026 •

edited

Loading

vyatkinv Apr 24, 2026 •

edited

Loading

epugh commented Apr 30, 2026 •

edited

Loading