Stream emulator data into workflow visualizer app #1374

wenli-cai · 2025-07-17T18:32:42Z

By using Unix Domain Sockets and adb forwarding, the visualizer is able to retrieve logged data directly from the emulator to display the workflow render passes.

The app has also been changed to allow for both File and Live tracing mode through a toggle.

Streamed data takes in a list of nodes at a time, but a trace file has lists of lists of nodes, so we use generics to differentiate them

Supplying generics don't seem to work and runs into error with nesting. This solution supplies a type for moshi and forces a cast to the desired type.

Extend TraceMode logic by using it to store the file/socket being used in the specific mode. The logic of rendering will depend on the type of TraceMode

Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Previously, the use of types and manually casting was due to type erasure. But using kotlin's typeOf allows us to still supply the nested types.

This will always show the most recent workflow

Since reader.readLine() is a blocking call, it's difficult to pause/end when socket.close() is called. Instead we just try-catch for when the error occurs after closing.

steve-the-edwards · 2025-07-22T17:15:05Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/App.kt

+  // Default to File mode, and can be toggled to be in Live mode.
+  var traceMode by remember { mutableStateOf<TraceMode>(TraceMode.File(null)) }
+  var selectedTraceFile by remember { mutableStateOf<PlatformFile?>(null) }
+  val socket = remember { SocketClient() }


Create this lazily so it only happens if we switch to streaming mode?

Looking at it lazily, it looks liek this is pretty lightweight, so not a big deal.

It does seem like a bit of a smell to create a network client in composition though, especially since this is a single-use object.

steve-the-edwards · 2025-07-22T17:16:05Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/App.kt

+    Thread {
+      socket.close()
+    }
+  )


Is this a JVM runtime API that @tcmulcahy was showing you? Not familiar with it.

Does this need to launch a Thread to do this so that it does not block shutdown? It would be good to have a comment why we need a new Thread for this.

From my understanding, shutdown hooks are registered by JVM and only ran once it starts the shutdown sequence. So it sort of makes sense that it needs to be on its own Thread. I'll make a comment on this

If the runtime is already shutting down, why do we care about blocking? And for that matter, why do we care about closing the socket at all in that case? The JVM/OS will close it for us once the process dies – you can't leak a socket outside a process boundary if you tried.

Also, it looks like this code is running directly in composition, which is extremely bad – it would add a new shutdown hook every time this composable recomposes.

About the point for having threads, it seem like addShutdownHook just takes a Thread and will run all registered hooks in a random order. I wasn't able to find anything that would allow you to add hooks without it being on a different thread. Do update me know, though, if there are ways to do that (so I know for the future too)!

Good point, I am not knowledgeable in this area so I didn't think about this. I had imagined that we ought to free the resources when provided an opportunity to do so, but this makes sense.

It's removed now.

steve-the-edwards · 2025-07-22T17:17:55Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/App.kt

  fun reset() {
    offset = Offset.Zero
-    scale = 1f
+    // scale = 1f


steve-the-edwards · 2025-07-22T17:21:22Z

...flow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/SocketClient.kt

+import java.net.SocketException
+
+/**
+ * This is a client that connects to the `ActionLogger` Unix Domain Socket and listens for any new


nit: not necessarily ActionLogger socket (though it is that in your branch). More importantly, just a publishing socket from an app. (Remember this is in Workflow library which can be used anywhere).

steve-the-edwards · 2025-07-22T17:24:06Z

...flow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/SocketClient.kt

+   * To better separate the responsibility of reading from the socket, we use a channel for the caller
+   * to handle parsing and amalgamating the render passes.
+   */
+  fun beginListen(scope: CoroutineScope) {


make this a suspend fun so we don't have to pass the CoroutineScope on the stack.

This makes the client handle the job/coroutine for this. Otherwise we are giving too much responsibility/power to this function with the CoroutineScope

steve-the-edwards · 2025-07-22T17:24:25Z

...flow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/SocketClient.kt

+   * This will always be called within an asynchronous call, so we do not need to block/launch a
+   * new coroutine here.


But, it does launch a new coroutine?

Turns out I dont understand coroutines at all, fixed the comment now.

You aren't the only one!

steve-the-edwards · 2025-07-22T17:25:13Z

...flow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/SocketClient.kt

+   * to handle parsing and amalgamating the render passes.
+   */
+  fun beginListen(scope: CoroutineScope) {
+    scope.launch(Dispatchers.IO) {


if you make this a suspend fun, this can just be

Suggested change

scope.launch(Dispatchers.IO) {

withContext(Dispatchers.IO) {

Then make the client handle launching a separate coroutine for this to run in the background.

➕

Fully together

suspend fun beginListen() = withContext(Dispatchers.IO) { // do all the stuff, now on an IO Thread pool backed coroutines dispatcher. }

But then beginListen would be a misnomer, since it doesn't just "begin" the listen, it is the whole listen. So a better name might be something like "consumeSocket" or something more descriptive.

Changed, changed name to. pollSocket as well.

steve-the-edwards · 2025-07-22T17:33:19Z

...flow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/SocketClient.kt

+        }
+      } catch (e: SocketException) {
+        println("Exiting socket listener due to: ${e.message}")
+      }


Don't we need to close the input stream in a finally here? Is the BufferedReader handling that behind the scense? I don't see how.

Just use the Closable.use {} extension.

Changed, I'm beginning to see how useful Closeable is

ericmaxwell2003 · 2025-07-22T17:43:40Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/App.kt

+    TraceModeToggleSwitch(
+      onToggle = {
+        resetStates()
+        traceMode = if (traceMode is TraceMode.Live) {


nit, consider calling the traceMode instance under evaluation as "currentTraceMode"

if(currentTraceMode is TraceMode.Live { } else { }

IMO, it's a bit clearer that the left side is the new state and the right side is existing state.

ericmaxwell2003 · 2025-07-22T17:50:59Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/ui/WorkflowTree.kt

+  fun handleParseResult(
+    parseResult: ParseResult,
+    onNewFrame: (() -> Unit)? = null
+  ): Boolean {


Nit, what's teh intent of this boolean? It seems like it always just returns whatever the value was of parseResult, and the result doesn't seem to be used elsewhere in your code anyway. Thoughts on just making it Unit? (no return type)

Yep, good catch. Removed

ericmaxwell2003 · 2025-07-22T17:55:07Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/ui/WorkflowTree.kt

+  LaunchedEffect(traceSource) {
+    when (traceSource) {
+      is TraceMode.File -> {
+        // We guarantee the file is null since this composable can only be called when a file is selected.


Do you mean you guarantee that it's "not" null?

One nit.. maybe you should do some sort of assertion/error here?

Like

checkNotNull(traceSource.file) { "traceSource.file should never be null here since this composable can only be called when a file is selected." }

Oops that's a typo, changed to a check now.
Is a check like this for readability? As in we can avoid having a comment here by stating explicitly (with code) that the file cannot be null? Or is it also useful to prevent us from having to use !!

ericmaxwell2003 · 2025-07-22T17:57:18Z

...flow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/SocketClient.kt

+    if (!initialized) {
+      return
+    }
+    socket.close()


Should you check for isClosed first?

I think in general, the start/close contract is unclear. Presumably calling start and close multiple times is not meaningful, so that should be documented in the kdoc, and enforced either by making them idempotent (i.e. calling start() again after calling it once does nothing, same for close()) or by throwing when multiple calls are detected.

I'm assuming @ericmaxwell2003 is referring to socket.isClosed, which I don't think you need to check, I would think socket.close() would be idempotent.

Changed, kdoc and the readme all clarifies this now.

If this class is intended to be single-use, you probably want to also close the channel here so that anything that tries to read from it sees there's no more data coming.

ericmaxwell2003 · 2025-07-22T18:00:07Z

...flow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/SocketClient.kt

+          renderPassChannel.trySend(input)
+        }
+      } catch (e: SocketException) {
+        println("Exiting socket listener due to: ${e.message}")


Should this be a log with the stack trace.

util.Log isn't available for KMP apps, should I look into 3rd party libraries for this?

Throwable.printStackTrace() is available in KMP.

ericmaxwell2003 · 2025-07-22T18:00:46Z

...flow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/SocketClient.kt

+   * `localabstract:` to connect to it.
+   */
+  fun start() {
+    initialized = true


Are we threadsafe here? just double checking, you may be

It should be, start() and close() are all called on the main thread. Speaking of which I should change the name to be open()

...flow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/SocketClient.kt

ericmaxwell2003 · 2025-07-22T18:13:04Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/ui/WorkflowTree.kt

+        withContext(Dispatchers.IO) {
+          // Since channel implements ChannelIterator, we can for-loop through on the receiver end.
+          for (renderPass in socket.renderPassChannel) {
+            val currentTree = if (fullTree.isEmpty()) null else fullTree.last()


Stylistic nit: fullTree.lastOrNull() could replace this if/else

zach-klippenstein · 2025-07-22T21:29:37Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/App.kt

+    Thread {
+      socket.close()
+    }
+  )


If the runtime is already shutting down, why do we care about blocking? And for that matter, why do we care about closing the socket at all in that case? The JVM/OS will close it for us once the process dies – you can't leak a socket outside a process boundary if you tried.

Also, it looks like this code is running directly in composition, which is extremely bad – it would add a new shutdown hook every time this composable recomposes.

zach-klippenstein · 2025-07-22T21:34:38Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/App.kt

  Box(
    modifier = modifier
  ) {
+    fun resetStates() = run {


What is run for here? Can't this just be

Suggested change

fun resetStates() = run {

fun resetStates() {

I'm not even sure what I was thinking, changed.

zach-klippenstein · 2025-07-22T21:40:14Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/Main.kt

+  Runtime.getRuntime().addShutdownHook(
+    Thread {
+      ProcessBuilder("adb", "forward", "--remove-all")
+        .start().waitFor()
+    }
+  )


Why use a shutdown hook instead of just normal control flow, i.e. wrapping singleWindowApplication in a try/finally and doing the cleanup in finally? You'd need to pass exitProcessOnExit = false. Imo that would make this code more straightforward.

zach-klippenstein · 2025-07-22T21:43:28Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/ui/WorkflowTree.kt

+        socket.beginListen(this)
+        val adapter: JsonAdapter<List<Node>> = createMoshiAdapter<Node>()
+
+        withContext(Dispatchers.IO) {


I don't think this code needs to be explicitly ran on Dispatchers.IO. I don't think any of it is doing system IO, it's all computation, so it should be on Dispatchers.Default.

zach-klippenstein · 2025-07-22T21:45:55Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/JsonParser.kt

+internal suspend fun parseFileTrace(
  file: PlatformFile,
 ): ParseResult {
  val jsonString = file.readString()


Does this readString do system IO directly? If so, it should be ran on Dispatchers.IO.

Does system IO mean something specific here? If not, PlatformFile.readString() is already dispatched onto the IO thread, so this should be okay.

zach-klippenstein · 2025-07-22T21:53:49Z

...flow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/SocketClient.kt

+          renderPassChannel.trySend(input)
+        }
+      } catch (e: SocketException) {
+        println("Exiting socket listener due to: ${e.message}")


Throwable.printStackTrace() is available in KMP.

zach-klippenstein · 2025-07-22T21:54:09Z

...flow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/SocketClient.kt

+        }
+      } catch (e: SocketException) {
+        println("Exiting socket listener due to: ${e.message}")
+      }


Just use the Closable.use {} extension.

zach-klippenstein · 2025-07-22T21:56:35Z

...flow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/SocketClient.kt

+    if (!initialized) {
+      return
+    }
+    socket.close()


I'm assuming @ericmaxwell2003 is referring to socket.isClosed, which I don't think you need to check, I would think socket.close() would be idempotent.

zach-klippenstein · 2025-07-22T22:01:30Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/ui/WorkflowTree.kt

 @Composable
-internal fun RenderDiagram(
-  traceFile: PlatformFile,
+internal fun RenderTrace(


This composable contains lots of logic related to parsing, not views. Might be worth considering factoring it out into a separate class, would be a lot more testable and keep the code in this file to actual view concerns.

But I don't mean you need to do it in this PR – just something to think about for later.

zach-klippenstein · 2025-07-22T22:02:43Z

...flow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/ui/FrameSelectTab.kt

+  LaunchedEffect(currentIndex) {
+    if (currentIndex < 0) return@LaunchedEffect
+    lazyListState.animateScrollToItem(currentIndex)
+  }


This is quite wasteful, launching a noop effect. Instead check currentIndex before even calling LaunchedEffect.

Suggested change

LaunchedEffect(currentIndex) {

if (currentIndex < 0) return@LaunchedEffect

lazyListState.animateScrollToItem(currentIndex)

}

if (currentIndex >= 0) {

LaunchedEffect(currentIndex) {

lazyListState.animateScrollToItem(currentIndex)

}

}

wenli-cai · 2025-07-23T16:32:30Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/ui/WorkflowTree.kt

+        }
+        if (error != null) {
+          return@LaunchedEffect
+        }


Can there be a situation where the if check happens before the launched coroutine is able to return an error? Manually testing it doesn't seem like it's the case, but I'm sure there's a better way of writing this bit of error handling

Yea this is definitely a race, the if check is pretty much guaranteed to run before the coroutine even starts since compose's dispatcher will dispatch the coroutine. And pollSocket is long-running – an error could happen at any time over the lifetime of the socket.

I think what you want to happen is that if the socket errors out, we just give up, so the loop that's reading from the socket below is cancelled. There are a few ways to do this, but if SocketClient is intended to be single-use, then probably the way that makes the most sense is to have pollSocket() close the channel after it returns. Then the for/in loop on line 119 will detect the socket is closed and complete. You can make SocketClient implement Closeable, close the channel in SocketClient.close(), and then use the use extension.

Probably worth rethinking the API of SocketClient and how it's used a bit to make something that's a bit more self-contained and safe. Maybe we should pair on it? Feel free to throw something on my calendar.

Implementing Closeable seems like a good idea, that would mean the responsibility for opening and closing the socket is more clear, right?

zach-klippenstein · 2025-07-23T18:10:49Z

...flow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/SocketClient.kt

+    if (!initialized) {
+      return
+    }
+    socket.close()


If this class is intended to be single-use, you probably want to also close the channel here so that anything that tries to read from it sees there's no more data coming.

zach-klippenstein · 2025-07-23T18:13:57Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/App.kt

+          frames get populated, so we avoid off by one when indexing into the frames.
+           */
+          frameIndex = -1
+          socket.open()


I would not open the socket here, since it's not clear who's responsible for closing it.

zach-klippenstein · 2025-07-23T18:14:22Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/ui/WorkflowTree.kt

+        }
+        if (error != null) {
+          return@LaunchedEffect
+        }


Yea this is definitely a race, the if check is pretty much guaranteed to run before the coroutine even starts since compose's dispatcher will dispatch the coroutine. And pollSocket is long-running – an error could happen at any time over the lifetime of the socket.

I think what you want to happen is that if the socket errors out, we just give up, so the loop that's reading from the socket below is cancelled. There are a few ways to do this, but if SocketClient is intended to be single-use, then probably the way that makes the most sense is to have pollSocket() close the channel after it returns. Then the for/in loop on line 119 will detect the socket is closed and complete. You can make SocketClient implement Closeable, close the channel in SocketClient.close(), and then use the use extension.

Probably worth rethinking the API of SocketClient and how it's used a bit to make something that's a bit more self-contained and safe. Maybe we should pair on it? Feel free to throw something on my calendar.

zach-klippenstein · 2025-07-23T18:27:06Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/App.kt

+  // Default to File mode, and can be toggled to be in Live mode.
+  var traceMode by remember { mutableStateOf<TraceMode>(TraceMode.File(null)) }
+  var selectedTraceFile by remember { mutableStateOf<PlatformFile?>(null) }
+  val socket = remember { SocketClient() }


It does seem like a bit of a smell to create a network client in composition though, especially since this is a single-use object.

Since the SocketClient was not complex to begin with, combining the start-poll-stop lifecycle within one function is much easier to maintain cleaner, rather than having the start/stop contract be unclear.

Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

zach-klippenstein

One last Compose UI thing to clean up, unrelated to the network stuff we discussed.

zach-klippenstein · 2025-07-24T19:52:56Z

...ace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/ui/TraceModeToggleSwitch.kt

+        checked = it
+        onToggle()


This is an anti-pattern, since you now have two sources of truth for traceMode and violates UDF. You don't need the checked property at all, just check the traceMode parameter every time. Or do something like

val isLive = traceMode is TraceMode.Live

since you check it below as well.

zach-klippenstein · 2025-07-24T19:54:59Z

workflow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/TraceParser.kt

+      is TraceMode.Live -> {
+        val adapter: JsonAdapter<List<Node>> = createMoshiAdapter<Node>()
+        streamRenderPassesFromDevice { renderPass ->
+          val currentTree = fullTree.lastOrNull()
+          val parseResult = parseLiveTrace(renderPass, adapter, currentTree)
+          handleParseResult(parseResult, onNewFrame)
+        }
+        error = "Socket has already been closed or is not available."


wenli-cai and others added 15 commits July 16, 2025 18:56

Log data retrieved from socket

e9579fc

Change moshi adapter to use generics

a121bf4

Streamed data takes in a list of nodes at a time, but a trace file has lists of lists of nodes, so we use generics to differentiate them

Create new toggle to switch between tracing modes

ccdd35c

Fix moshi adapter

f678ab7

Supplying generics don't seem to work and runs into error with nesting. This solution supplies a type for moshi and forces a cast to the desired type.

Extract socket setup and reading logic.

c63c43a

WIP

d326385

Consolidate logic to take in TraceMode rather than specific params

6e71ae9

Extend TraceMode logic by using it to store the file/socket being used in the specific mode. The logic of rendering will depend on the type of TraceMode

Apply changes from apiDump

f5fdb6e

Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Stream data from emulator directly into visualizer

8c1b2dd

Return to using generics for Moshi adapter

9d50d60

Previously, the use of types and manually casting was due to type erasure. But using kotlin's typeOf allows us to still supply the nested types.

Allow for auto scrolling during Live Mode

70c9b45

This will always show the most recent workflow

Fix SocketException

e233921

Since reader.readLine() is a blocking call, it's difficult to pause/end when socket.close() is called. Instead we just try-catch for when the error occurs after closing.

Fix lint violations

f414e75

Consolidate live and trace mode render on result logic

fff11db

Clean up compose violations

cd8b4ab

Base automatically changed from wenli/visualizer-ui-improvements to main July 18, 2025 17:53

Change function visibility for test

a5d20ac

wenli-cai marked this pull request as ready for review July 18, 2025 18:12

wenli-cai requested review from a team and zach-klippenstein as code owners July 18, 2025 18:12

wenli-cai changed the title ~~Wenli/visualizer uds~~ Stream emulator data into workflow visualizer app Jul 18, 2025

wenli-cai assigned wenli-cai and steve-the-edwards and unassigned wenli-cai Jul 18, 2025

wenli-cai and others added 2 commits July 18, 2025 14:48

Merge branch 'main' into wenli/visualizer-uds

b8c62ab

Fix merge bug

febd6d5

steve-the-edwards reviewed Jul 22, 2025

View reviewed changes

ericmaxwell2003 reviewed Jul 22, 2025

View reviewed changes

...flow-trace-viewer/src/jvmMain/kotlin/com/squareup/workflow1/traceviewer/util/SocketClient.kt Show resolved Hide resolved

ericmaxwell2003 reviewed Jul 22, 2025

View reviewed changes

zach-klippenstein requested changes Jul 22, 2025

View reviewed changes

Fix PR comments

764f991

wenli-cai commented Jul 23, 2025

View reviewed changes

Extract parsing logic from tree rendering logic

a0f22da

zach-klippenstein reviewed Jul 23, 2025

View reviewed changes

Refactor SocketClient

2ae9051

Since the SocketClient was not complex to begin with, combining the start-poll-stop lifecycle within one function is much easier to maintain cleaner, rather than having the start/stop contract be unclear.

wenli-cai force-pushed the wenli/visualizer-uds branch from 93730e6 to 2ae9051 Compare July 24, 2025 13:47

wenli-cai and others added 2 commits July 24, 2025 13:52

Apply changes from apiDump

a03fcc9

Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

More socket refactoring

be3fbd1

wenli-cai force-pushed the wenli/visualizer-uds branch from d46ff02 to be3fbd1 Compare July 24, 2025 16:19

Apply changes from apiDump

9319e1d

Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

japplin approved these changes Jul 24, 2025

View reviewed changes

steve-the-edwards approved these changes Jul 24, 2025

View reviewed changes

zach-klippenstein approved these changes Jul 24, 2025

View reviewed changes

wenli-cai and others added 2 commits July 24, 2025 17:42

Fix more pr comment and coroutine bug

66010f9

Merge branch 'main' into wenli/visualizer-uds

3a93534

wenli-cai merged commit b6e70a0 into main Jul 25, 2025
69 checks passed

wenli-cai deleted the wenli/visualizer-uds branch July 25, 2025 02:43

		* This will always be called within an asynchronous call, so we do not need to block/launch a
		* new coroutine here.

Stream emulator data into workflow visualizer app #1374

Stream emulator data into workflow visualizer app #1374

Uh oh!

Conversation

wenli-cai commented Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

wenli-cai Jul 22, 2025 • 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!

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!

wenli-cai Jul 23, 2025 • 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

wenli-cai commented Jul 17, 2025 •

edited

Loading

wenli-cai Jul 22, 2025 •

edited

Loading

wenli-cai Jul 23, 2025 •

edited

Loading