[3.7.0] Data type not recognized by value unpacker. at valueUnpacker (WorkletRuntime::WorkletRuntime:1:1477) #5660

efstathiosntonas · 2024-02-12T07:27:08Z

Description

Cannot reproduce it locally, for now I've encountered in production builds on Androids 11,12,13,14.

Error:
Data type not recognized by value unpacker. at valueUnpacker (WorkletRuntime::WorkletRuntime:1:1477)

Full stacktrace:

com.facebook.jni.CppException: [Reanimated] Data type not recognized by value unpacker.

Error: [Reanimated] Data type not recognized by value unpacker.
    at valueUnpacker (WorkletRuntime::WorkletRuntime:1:1477)
        at com.swmansion.reanimated.AndroidUIScheduler.triggerUI(AndroidUIScheduler.java:-2)
        at com.swmansion.reanimated.AndroidUIScheduler$1.run(AndroidUIScheduler.java:24)
        at com.swmansion.reanimated.AndroidUIScheduler$2.runGuarded(AndroidUIScheduler.java:43)
        at com.facebook.react.bridge.GuardedRunnable.run(GuardedRunnable.java:29)
        at android.os.Handler.handleCallback(Handler.java:938)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loop(Looper.java:250)
        at android.app.ActivityThread.main(ActivityThread.java:7755)
        at java.lang.reflect.Method.invoke(Method.java:-2)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:958)

Steps to reproduce

Updated to 3.7.0 from 3.6.2
crashes

Snack or a link to a repository

no-repo-cannot-reproduce

Reanimated version

3.7.0

React Native version

0.73.4

Platforms

Android

JavaScript runtime

Hermes

Workflow

React Native

Architecture

Paper (Old Architecture)

Build type

Release app & production bundle

Device

Real device

Device model

LG G8 ThinQ™ (LM-G820), Mi Note 10, Galaxy S22 Ultra (SM-S908U), moto g(8) power

Acknowledgements

Yes

The text was updated successfully, but these errors were encountered:

github-actions · 2024-02-12T07:27:22Z

Hey! 👋

The issue doesn't seem to contain a minimal reproduction.

Could you provide a snack or a link to a GitHub repository under your username that reproduces the problem?

joe-sam · 2024-02-12T08:02:58Z

I don't know if this is related but while testing a PR #5216 I found that some AP initWithContext/NativeProxy I had to add a non optional parameter which is a valueUnpackerCode of type String. You may have to include this missing argument/type in some function call or provide its default value.

efstathiosntonas · 2024-02-12T12:48:58Z

@joe-sam thanks for the heads up, can you please be more specific? What is AP?

where this code should be placed?

public void initWithContext(ReactApplicationContext reactApplicationContext, String valueUnpackerCode) {
   mReactApplicationContext = reactApplicationContext;
   mNativeProxy = new NativeProxy(reactApplicationContext, valueUnpackerCode);
   mAnimationManager.setAndroidUIScheduler(getNativeProxy().getAndroidUIScheduler());
   compatibility = new ReaCompatibility(reactApplicationContext);
   compatibility.registerFabricEventListener(this);
 }

joe-sam · 2024-02-13T04:38:12Z

@efstathiosntonas

AP was a typo I meant API interface. valueUnpackerCode is a new argument to initContext/nativeProxy. You possibly may have multiple mismatched library versions that might be trying to invoke the reanimated API from the earlier/later library interface.
I had to pin the resolutions for the peer dependency in my package.json before my incompatibility issues went away.

This code snippet comes from here .

anders-friis-topdk · 2024-02-14T09:05:15Z

This issue is causing many crashes in my project after updating to React Native 0.73.4, Reanimated 3.7.0 and old architecture. It crashes often but not consistently so it's hard to come up with a repro but I am looking into it.
I also tried downgrading to previous Reanimated version, but it doesn't seem to be compatible with RN 0.73.4 so we are stuck with these crashes at the moment.
I checked our yarn.lock file and it doesn't seem there are multiple reanimated versions in play.

Can you elaborate on the potential fix your mention with initWithContext, @efstathiosntonas or @joe-sam ?

efstathiosntonas · 2024-02-14T10:05:37Z

@anders-friis-topdk use version 3.6.2, it works with rn 0.73.x.

unfortunately I do not have the time to look into this at this moment, I've downgraded to 3.6.2 for the time being.

edit: I used 3.7.0 in the entire project, I did not have conflicting versions (otherwise the app wouldn't run at all)

anders-friis-topdk · 2024-02-14T12:26:26Z

@efstathiosntonas
I just tried downgrading to 3.6.2 and this time I succeeded. Must have been some cache problem last time I tried.
I cannot get the app to crash now so that seems to solve it for now :) Thanks!

joe-sam · 2024-02-14T18:04:09Z

I am on RN 0.72.10.
I found that multiple package.json peer libraries use different peer dependencies of react-native-reanimated which were completely version confused although this did not show up in yarn.lock
So when resolving I did the following standard methods to try to flush the cache(s?) and pin the version. This worked locally in __DEV__ but don't know whether this works with PROD.
I also pinned the peer dependency resolution of reanimated library by injecting this into package.json


   "resolutions": {
    "react-native-reanimated": "3.7.0"
   }

efstathiosntonas · 2024-02-15T11:41:43Z

@joe-sam did you managed to check if your prod version crash after pinning the version in resolutions?

efstathiosntonas · 2024-02-16T17:51:17Z

@tjzel @tomekzaw hey guys, care to explain why this might be throwing and if there's a way to track it down on our reanimated hooks? Thanks!

talaikis · 2024-02-18T15:18:18Z

Same with RN 0.73.4. Had no such problem with RN 0.72 and 3.3.0. Resolution does nothing in prod.

tomekzaw · 2024-02-18T17:34:15Z

Hey @efstathiosntonas, thanks for reporting this issue.

I don't know if this is related but while testing a PR #5216 I found that some AP initWithContext/NativeProxy I had to add a non optional parameter which is a valueUnpackerCode of type String. You may have to include this missing argument/type in some function call or provide its default value.

@joe-sam This API is private and used only internally, you should never need to make any changes to it.

You possibly may have multiple mismatched library versions that might be trying to invoke the reanimated API from the earlier/later library interface. I had to pin the resolutions for the peer dependency in my package.json before my incompatibility issues went away.

@joe-sam Having multiple versions of Reanimated installed at once usually breaks things. That's why in #4914 (released in 3.6.0) we added a runtime check that asserts that only one instance of Reanimated is present:

react-native-reanimated/src/reanimated2/NativeReanimated/NativeReanimated.ts

Lines 71 to 81 in b9caec4

    
           function assertSingleReanimatedInstance() { 
        
             if ( 
        
               global._REANIMATED_VERSION_JS !== undefined && 
        
               global._REANIMATED_VERSION_JS !== jsVersion 
        
             ) { 
        
               throw new Error( 
        
                 `[Reanimated] Another instance of Reanimated was detected. 
        
           See \`https://docs.swmansion.com/react-native-reanimated/docs/guides/troubleshooting#another-instance-of-reanimated-was-detected\` for more details. Previous: ${global._REANIMATED_VERSION_JS}, current: ${jsVersion}.` 
        
               ); 
        
             } 
        
           }

For more details, see https://docs.swmansion.com/react-native-reanimated/docs/guides/troubleshooting/#multiple-versions-of-reanimated-were-detected.

We recommend the solution from #5660 (comment).

hey guys, care to explain why this might be throwing and if there's a way to track it down on our reanimated hooks?

Sure, the error comes from this else statement:

react-native-reanimated/src/reanimated2/valueUnpacker.ts

Lines 65 to 67 in b9caec4

    
           } else { 
        
             throw new Error('[Reanimated] Data type not recognized by value unpacker.'); 
        
           }

When copying JS values from RN runtime to UI runtime (e.g. worklet closure), they are first serialized from JS values to C++ shareables (intermediate format, runtime-agnostic data structures) and then parsed from C++ shareables to JS values.

valueUnpacker is a function used to parse more complex objects like worklets or remote functions.

The error in the issue description states that valueUnpacker cannot re-create passed object. Without a repro, it's really difficult to tell what exactly goes wrong.

efstathiosntonas · 2024-02-18T17:39:57Z

thanks @tomekzaw for the detailed explanation.

It seems that we need to revisit our animated hooks and methods and change things around. This is not an issue with 3.6.2 so recent changes have caused this.

Question is, are you going to revisit this else/if function and improve it/fix it? If not, this is breaking the API on several npm modules with reanimated as a dep since according to my bugsnag reports there are 2 npm modules that cause this crash. It's really hard to reproduce though 🤷‍♂️

tomekzaw · 2024-02-18T17:46:14Z

Honestly, I'd like to eliminate valueUnpacker as soon as possible. This function is implemented in JS and we need to pass its source code from JS to native side in installTurboModule which makes things overly complicated. Currently, it's used in three different places and we can decouple them:

ShareableWorklet::toJSValue – valueUnpacker creates and memoizes worklets
ShareableHandle::toJSValue – valueUnpacker memoizes handles
ShareableRemoteFunction::toJSValue – valueUnpacker adds logic for "Tried to synchronously call" error

I think I will submit a PR with a small refactor.

tomekzaw · 2024-02-21T13:56:51Z

@efstathiosntonas As described above, valueUnpacker is responsible for converting worklets, remote functions and values with initializers. However, the provided error clearly states that it has been called for something else that does not fall into any of these categories. This means that even if we refactor each individual branch, the error is still likely to persist.

At this point, we need to know what object caused valueUnpacker to fail. However, you have mentioned that you cannot reproduce the issue locally. Is there any way we could at least see what object causes the error? This could be easily done by appending the error message with the string representation of the object to unpack:

  } else { 
-   throw new Error('[Reanimated] Data type not recognized by value unpacker.'); 
+   throw new Error('[Reanimated] Data type not recognized by value unpacker.' + ' String(objectToUnpack)); 
  }

alexstanbury · 2024-02-21T18:36:52Z

I'm having the same issue and can recreate it approx 1 in 5 times in my app by following a certain sequence. With your code amendment String(objectToUnpack) I get [Object object] appended to the end, and with JSON.stringify(objectToUnpack, null, 2) I get {}, an empty object.

I'm using 3.7.0 and RN 0.73.4

This crash is happening on Android, interestingly I get a different one if I follow the same sequence on iOS. I will update that tomorrow.

efstathiosntonas · 2024-02-21T20:24:35Z

thanks @alexstanbury, @tomekzaw no matter how many times I try I cannot get it to crash in my environment, sorry 🫤

The part of the code where this crashes was working perfectly fine on < 3.7.0, it srarted showing up after the upgrade on my bugsnag logs.

edit: this module creates the crash: https://github.com/SimformSolutionsPvtLtd/react-native-reactions

tomekzaw · 2024-02-21T21:31:49Z

@alexstanbury Can you try _toString(objectToUnpack) instead?

joe-sam · 2024-02-22T04:52:28Z

The current stack trace is useless as when this error/exception occurs a redundant stack trace is printed.
My suggestion is since all supported versions of react-native can finally handle non-standard error objects (facebook/react-native#42079) perhaps a stack trace of the other thread could be injected into the wrapper object (objectToPack) before it is initially marshalled/serialized by the valuePacker. This can be useful device for debugging and it would at the very minimum show the file where the exception was actually thrown. You can delete this stacktrace(or remove the wrapper) if un-marshalled/deserialized successfully or enable this only during development.

tomekzaw · 2024-02-22T07:53:03Z

@joe-sam Just to confirm that I understand your proposal correctly – your idea is to get the stack trace from the RN runtime when the value is serialized from JS value into a C++ intermediate form (technically, this is called makeShareableClone) and then include that string in the C++ serializable form, so that we can access it when parsing back from C++ to JS value in valueUnpacker?

This way we would at least know the origin of the values copied into the UI runtime, in terms of what functions passed them to makeShareableClone. On the other hand, we still wouldn't exactly know anything about the values itself (type, keys etc.).

alexstanbury · 2024-02-22T08:05:17Z

I'll be testing & recreating this morning so if you can provide instructions on how to make the above changes, I'll give it a go.

dpyeates · 2024-02-22T08:06:09Z

I am seeing this in production as well. RN0.73.4, Reanimated 3.7.0.

tomekzaw · 2024-02-22T08:17:51Z

@dpyeates Thanks for letting us know!

@alexstanbury Great to hear, thanks in advance! Let's start with the following change that should print more information about the failing value:

  } else { 
-   throw new Error('[Reanimated] Data type not recognized by value unpacker.'); 
+   throw new Error('[Reanimated] Data type not recognized by value unpacker.' + ' _toString(objectToUnpack)); 
  }

SukumarRN7 · 2024-02-22T08:21:02Z

Happening on

"react-native": "^0.72.0",
"react-native-reanimated": "^3.6.1",

This was working fine with the same above versions since 2 months i guess,
and suddenly it started coming up since yesterday and frequency is quiet high as well.

joe-sam · 2024-02-22T10:00:00Z

@tomekzaw Yes, essentially correct (and could be hidden behind a feature flag), so as to easily create a reproducer which is only possible if we know the context of the exception.

efstathiosntonas · 2024-02-29T13:34:49Z

@tjzel don't know if it makes any sense but iOS is in ~~2000~~ 3000 renders (17 25minutes) using this neat polyfill console.count() https://github.com/MaxGraey/react-native-console-time-polyfill and it still hasn't crashed while on Android it crashed in the first 2 minutes.

edit: the app won't crash on simulator, just the red screen of death, the counter is keep going though on the background.

simulator screenshot:

Click me

Elrohil44 · 2024-02-29T13:38:32Z

Well, for me it also happens randomly. Sometimes it happens every 5 minutes and sometimes it is running for several minutes without error. In my case, I am testing it on Android, so maybe indeed Android has a higher chance to trigger error.

Edit: That is correct, there is an error on the red screen with this stacktrace, but you can dismiss it and the app still works

SukumarRN7 · 2024-03-01T06:27:22Z

@tjzel this is also happening on IOS.

in production, although it didnot print any stack trace.

tsogzark · 2024-03-02T09:59:00Z

I have encountered the same stack trace. This issue manifests on my Android and iPad devices with an approximate probability of 1 in 50.Thanks to guys who are working on the issue.

version: 3.7.2

aspidvip · 2024-03-04T10:08:20Z

me to

tjzel · 2024-03-04T11:10:59Z

Thanks everyone for your effort here. Thanks to reproduction postem by @Elrohil44 we managed to find the underlying problem and it's a race condition. We will soon patch this up and try to release Reanimated 3.8.0 shortly afterwards.

@piaskowyk

…ds (#5759) ## Summary Fixes #5660, a regression introduced in #4300. The aforementioned race condition happens this way: 1. An object using a `ShareableHandle` underneath (e.g. a shared value) is created. 2. This object is accessed on UI thread. 3. The initializer of this `ShareableHandle` get called on the UI thread. 4. At the same time, JS thread schedules an operation on this object (e.g. setting a value of shared value). 5. Access on UI thread forces the initialization. The condition of the if clause resolves to true and UI thread tries to access the runtime. ![Screenshot 2024-03-04 at 13 00 07](https://github.com/software-mansion/react-native-reanimated/assets/40713406/6c124599-3d60-4211-a1a9-3ccedd88f687) 6. However, access from JS thread has locked the runtime and causes the UI runtime to wait. 7. Then, JS thread enters the same if clause body and initializes the whole shareable. 8. After initializing and releasing the runtime, UI thread gets unblocked. 9. However, now `initializer_` has been nulled and causes memory access issues. It's difficult to change the whole flow of locking to prevent such scenarios. Therefore we won't null the `initializer_` object anymore. However, this won't fix the problem of potential double initialization. Luckily, the code of `valueUnpacker` already prevents that with its shareable handle cache and the fact that runtime operations must be sequential. ## Test plan Run the following race condition reproduction made - you should re-run the app several times (probably up to 20ish) since it's most likely to happen when the app starts. It's also more likely to happen on Android simulators (at least for me). <details> <summary> Test code </summary> ```tsx import {useSharedValue} from 'react-native-reanimated'; import {useEffect, useState} from 'react'; const value = 666666; const Screen = () => { const sv = useSharedValue(value); useSharedValue(1); useSharedValue(2); useSharedValue(3); sv.value = value; useEffect(() => { // eslint-disable-next-line @typescript-eslint/no-unused-vars const currentValue = sv.value; }, [sv]); return null; }; const ReanimatedCrashReproduction = () => { const [render, setRender] = useState(false); useEffect(() => { const interval = setInterval(() => setRender(r => !r), 500); return () => clearInterval(interval); }, []); return render ? <Screen /> : null; }; export default ReanimatedCrashReproduction; ``` </summary> You can do the following to see that double initialization happens still, but all is well 🚰. ![Screenshot 2024-03-06 at 10 06 50](https://github.com/software-mansion/react-native-reanimated/assets/40713406/6517cd3a-eea0-45ef-bd18-a15215272f13) Big thanks to @piaskowyk for the debugging help 🚀

efstathiosntonas · 2024-03-06T13:45:23Z

@tjzel thank you for fixing this 🔥 , is there an ETA for 3.8.0 😅 ?

tjzel · 2024-03-06T13:49:13Z

tjzel · 2024-03-06T13:50:07Z

It's an absolute priority for us to ship production crash fixes asap 🚤

efstathiosntonas · 2024-03-06T13:55:15Z

finally I'll get rid of 1K lines of my monkey(donkey-dog-cat)-patch of reanimated

angelica-snowit · 2024-03-08T09:52:56Z

still waiting a patch for this :'(

tomekzaw · 2024-03-08T10:07:13Z

@angelica-snowit This issue was fixed with #5759 which has already been merged to main and thus should be also released as nightly on npm. Please try yarn add react-native-reanimated@nightly.

tmitchel2 · 2024-03-08T15:32:54Z

I downgraded to 3.6.3 but im still getting this issue. Is that expected and is it known which version is the last known good version?

efstathiosntonas · 2024-03-08T16:01:56Z

@tmitchel2 this started after upgrading to 3.7.0, never encountered it on 3.6.2, it shouldn't happen in 3.6.3 though since it only included some web fixes in comparison to 3.6.2 according to the release notes.

Did you cleaned your project and metro cache after downgrading?

SukumarRN7 · 2024-03-08T16:42:26Z

@tmitchel2 Can you give a look on ur npm/yarn lock file

check for if reanimated is pointing to 3.6.2 but is still referring to use 3.7.0 because of "^" sign.
You might need to change that explicitly to use 3.6.2 .

This can be the culprit !!

tmitchel2 · 2024-03-08T16:51:53Z

I had the exact same thought and when I downgraded again I locked it down to 3.6.1, but actually looking back in git I can see it was indeed still using 3.7.1 in the lockfile

(facepalm)

:)

efstathiosntonas · 2024-03-08T17:09:39Z

3.8.0 is out, thanks @tjzel ❤️

tomgreco · 2024-04-16T13:25:52Z

I'm getting this error on 3.8.1 with jest.

 node_modules/react-native-reanimated/src/reanimated2/valueUnpacker.ts:67:94 - error TS2552: Cannot find name '_toString'. Did you mean 'toString'?

    67       `[Reanimated] Data type in category "${category}" not recognized by value unpacker: "${_toString(
                                                                                                    ~~~~~~~~~

      node_modules/typescript/lib/lib.dom.d.ts:18181:18
        18181 declare function toString(): string;

andrecrimb · 2024-04-30T13:48:26Z

I'm still getting this in 3.8.1.

quantumperception · 2024-05-28T03:56:08Z

I was getting this in Jest tests. I was mocking using react-native-reanimated/mock, solved it by using jest.mock('react-native-reanimated') instead.

RN 0.74.1, Expo SDK 51, Reanimated 3.10.1

github-actions bot added the Missing repro This issue need minimum repro scenario label Feb 12, 2024

github-actions bot added the Platform: Android This issue is specific to Android label Feb 12, 2024

This was referenced Feb 19, 2024

Extract remote function logic from value unpacker #5686

Draft

Extract initializer logic from value unpacker #5687

Draft

Extract worklet logic from value unpacker #5688

Draft

tjzel mentioned this issue Mar 4, 2024

Fix race condition when ShareableHandle is accessed on multiple threads #5759

Merged

Latropos added the Unable to repro label Mar 5, 2024

Latropos mentioned this issue Mar 5, 2024

Better error when passing easing from 'react-native' instead of 'reanimated' #5639

Merged

Latropos added Repro provided A reproduction with a snippet of code, snack or repo is provided and removed Unable to repro Missing repro This issue need minimum repro scenario labels Mar 5, 2024

tjzel closed this as completed in #5759 Mar 6, 2024

tjzel mentioned this issue Mar 6, 2024

Android crashed in production mode (APK) #5762

Closed

tienifr mentioned this issue Apr 22, 2024

[$250] [HOLD for payment 2024-06-05] Investigate android com.facebook.jni.CppException crash Expensify/App#40699

Closed

[3.7.0] Data type not recognized by value unpacker. at valueUnpacker (WorkletRuntime::WorkletRuntime:1:1477) #5660

[3.7.0] Data type not recognized by value unpacker. at valueUnpacker (WorkletRuntime::WorkletRuntime:1:1477) #5660

Comments

efstathiosntonas commented Feb 12, 2024 • edited Loading

Description

Steps to reproduce

Snack or a link to a repository

Reanimated version

React Native version

Platforms

JavaScript runtime

Workflow

Architecture

Build type

Device

Device model

Acknowledgements

github-actions bot commented Feb 12, 2024

joe-sam commented Feb 12, 2024

efstathiosntonas commented Feb 12, 2024

joe-sam commented Feb 13, 2024

anders-friis-topdk commented Feb 14, 2024

efstathiosntonas commented Feb 14, 2024 • edited Loading

anders-friis-topdk commented Feb 14, 2024

joe-sam commented Feb 14, 2024

efstathiosntonas commented Feb 15, 2024

efstathiosntonas commented Feb 16, 2024 • edited Loading

talaikis commented Feb 18, 2024

tomekzaw commented Feb 18, 2024 • edited Loading

efstathiosntonas commented Feb 18, 2024 • edited Loading

tomekzaw commented Feb 18, 2024

tomekzaw commented Feb 21, 2024

alexstanbury commented Feb 21, 2024 • edited Loading

efstathiosntonas commented Feb 21, 2024 • edited Loading

tomekzaw commented Feb 21, 2024

joe-sam commented Feb 22, 2024

tomekzaw commented Feb 22, 2024 • edited Loading

alexstanbury commented Feb 22, 2024

dpyeates commented Feb 22, 2024

tomekzaw commented Feb 22, 2024

SukumarRN7 commented Feb 22, 2024

joe-sam commented Feb 22, 2024

efstathiosntonas commented Feb 29, 2024 • edited Loading

Elrohil44 commented Feb 29, 2024 • edited Loading

SukumarRN7 commented Mar 1, 2024

tsogzark commented Mar 2, 2024

aspidvip commented Mar 4, 2024

tjzel commented Mar 4, 2024

efstathiosntonas commented Mar 6, 2024 • edited Loading

tjzel commented Mar 6, 2024

tjzel commented Mar 6, 2024

efstathiosntonas commented Mar 6, 2024 • edited Loading

angelica-snowit commented Mar 8, 2024

tomekzaw commented Mar 8, 2024

tmitchel2 commented Mar 8, 2024

efstathiosntonas commented Mar 8, 2024 • edited Loading

SukumarRN7 commented Mar 8, 2024 • edited Loading

tmitchel2 commented Mar 8, 2024

efstathiosntonas commented Mar 8, 2024

tomgreco commented Apr 16, 2024 • edited Loading

andrecrimb commented Apr 30, 2024

quantumperception commented May 28, 2024 • edited Loading

efstathiosntonas commented Feb 12, 2024 •

edited

Loading

efstathiosntonas commented Feb 14, 2024 •

edited

Loading

efstathiosntonas commented Feb 16, 2024 •

edited

Loading

tomekzaw commented Feb 18, 2024 •

edited

Loading

efstathiosntonas commented Feb 18, 2024 •

edited

Loading

alexstanbury commented Feb 21, 2024 •

edited

Loading

efstathiosntonas commented Feb 21, 2024 •

edited

Loading

tomekzaw commented Feb 22, 2024 •

edited

Loading

efstathiosntonas commented Feb 29, 2024 •

edited

Loading

Elrohil44 commented Feb 29, 2024 •

edited

Loading

efstathiosntonas commented Mar 6, 2024 •

edited

Loading

efstathiosntonas commented Mar 6, 2024 •

edited

Loading

efstathiosntonas commented Mar 8, 2024 •

edited

Loading

SukumarRN7 commented Mar 8, 2024 •

edited

Loading

tomgreco commented Apr 16, 2024 •

edited

Loading

quantumperception commented May 28, 2024 •

edited

Loading