androidx.datastore crashes with java.io.FileNotFoundException: /data/user/0/com.app.id/files/datastore/a_datastore.preferences_p [337870543]

Fixed

Bug

Status Update

No update yet.

Description

mk...@opera.com

created issue #1

Apr 30, 2024 06:11AM

DataStore Component used: androidx.datastore for Android DataStore Version used: 1.1.0 Devices/Android versions reproduced on: Seems not connected to any specific device/Android version as we see it on many different ones on all Android versions.

After updating androidx.datastore from 1.0.0 to 1.1.0 we started to see a lot of the following crashes.

Fatal Exception: java.io.FileNotFoundException: /data/user/0/com.app.id/files/datastore/a_datastore.preferences_pb: open failed: ENOENT (No such file or directory)
       at libcore.io.IoBridge.open(IoBridge.java:574)
       at java.io.FileInputStream.<init>(FileInputStream.java:160)
       at okio.Okio__JvmOkioKt.source(Okio__JvmOkio.kt:181)
       at okio.Okio.source(Okio.java:1)
       at okio.JvmSystemFileSystem.source(JvmSystemFileSystem.kt:96)
       at androidx.datastore.core.okio.OkioReadScope.readData$suspendImpl(OkioStorage.kt:227)
       at androidx.datastore.core.okio.OkioReadScope.readData(OkioStorage.kt:1)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invokeSuspend(StorageConnection.kt:74)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.okio.OkioStorageConnection.readScope(OkioStorage.kt:113)
       at androidx.datastore.core.StorageConnectionKt.readData(StorageConnection.kt:74)
       at androidx.datastore.core.DataStoreImpl.readDataFromFileOrDefault(DataStoreImpl.kt:331)
       at androidx.datastore.core.DataStoreImpl.access$readDataFromFileOrDefault(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invokeSuspend(DataStoreImpl.kt:378)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataOrHandleCorruption(DataStoreImpl.kt:377)
       at androidx.datastore.core.DataStoreImpl.access$readDataOrHandleCorruption(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invokeSuspend(DataStoreImpl.kt:314)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataAndUpdateCache(DataStoreImpl.kt:312)
       at androidx.datastore.core.DataStoreImpl.access$readDataAndUpdateCache(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readState$2.invokeSuspend(DataStoreImpl.kt:234)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
       at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:111)
       at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:99)
       at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:585)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:802)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:706)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:693)

The crashes happen on app startup when we try read from the datastore early in the app startup process. We see a lot of them in the wild. Happened to us locally few times as well, but it's very rare and unpredictable which makes it hard to debug.
Among other calls we use runBlocking to read from the datastore in one place
Our app is single process and we only create the datastore once
We use single process datastore (the code didn't change after updating the lib)

Comments

mk...@opera.com <mk...@opera.com> #2Apr 30, 2024 07:37AM

Hi,

Thank you for your feedback. Could you help provide logs when the issue occurs and if possible a code snippet of the part that uses CameraX, it will help us find the root cause.

A quick question: does this issue occur on other devices, or only on Samsung Galaxy M55.

se...@opera.com <se...@opera.com> #3May 8, 2024 09:17AM

Hey,
attaching the logs.
The issue is only reproducible of M55. We have not met this on any other.

to...@gmail.com <to...@gmail.com> #4May 27, 2024 12:41PM

Thank you,

CameraX uses OpenGL for sharing stream between Preview and VideoCapture to provide use case combinations beyond device's native capabilities. When using Preview + ImageAnalysis or Preview + VideoCapture, the device capabilities are usually not exceeded, so stream sharing is not used. So this could be a device specified issue related to OpenGL.

We will attempt to acquire the reported device model for testing.

mk...@opera.com <mk...@opera.com> #5Jun 13, 2024 11:35AM

Thanks for the update,
Yes I'm aware that stream sharing is not a hardware supported feature.
Please let me know if we could assist in any way to solve the issue.

di...@gmail.com <di...@gmail.com> #6Jul 1, 2024 09:02AM

Hey guys,
Is there any update on this? Were you able to find the phone? Could we assist here somehow?

da...@asana.com <da...@asana.com> #7Jul 12, 2024 12:20AM

Thank you for your kind reply! I think we will receive the phone in a while and we will update if we find anything.

mi...@outlook.com <mi...@outlook.com> #8Jul 17, 2024 07:35PM

Hi,

We got the device and did some investigating. The root cause seems to be that Samsung M55 has issues when using ImageAnalysis with another stream that uses TEMPLATE_RECORD, which is typically used by VideoCapture or by a stream shared between VideoCapture and Preview.

The issue also occurs when only ImageAnalysis and VideoCapture are bound. The video can only obtain the first few frames in this case.

We will fix this issues in a future release. One workaround you can try is to bind an additional ImageCaputre usecase (binds all 4 usecases), it seems the stream is normal in this situation.

Thanks for finding this bug!

ju...@ratpsmartsystems.com <ju...@ratpsmartsystems.com> #9Jul 18, 2024 01:06PM

Hi,
thank you for the information provided.
Is it possible that the bug will be fixed in 1.3.* release? It seems quite severe as it blocks main functionality.

br...@linear.app <br...@linear.app> #10Aug 19, 2024 06:18PM

Since in #comment1 the error was reported for the 1.4.1 release, maybe you meant 1.4.* release?

We will fix on both the 1.4 stable release, and the current 1.5 release. For 1.3, it is recommended to migrate to the 1.4 stable version. Or use one of the following workarounds:

bind an addiotional ImageCapture use case
use Camera2Interop to change VideoCapture builder's CONTROL_CAPTURE_INTENT to CONTROL_CAPTURE_INTENT_PREVIEW. As in the following code snippet:

VideoCapture.Builder<Recorder> videoCaptureBuilder = new VideoCapture.Builder<>(recorder);
new Camera2Interop.Extender<>(videoCaptureBuilder).setCaptureRequestOption(CaptureRequest.CONTROL_CAPTURE_INTENT, CaptureRequest.CONTROL_CAPTURE_INTENT_PREVIEW);

mk...@opera.com <mk...@opera.com> #11Aug 19, 2024 06:54PM

Hi,
you're correct I meant 1.4.*.
Thanks for the clarification!

dc...@openai.com <dc...@openai.com> #12Sep 23, 2024 10:58PM

Project: platform/frameworks/support
Branch: androidx-main
Author: mingdatsai <mingdatsai@google.com>
Link: https://android-review.googlesource.com/3529969

Fix preview freeze when using ImageAnalysis with a TEMPLATE_RECORD stream

Expand for full commit details

Fix preview freeze when using ImageAnalysis with a TEMPLATE_RECORD stream 
 
Fixed preview freeze issue when using ImageAnalysis with another stream 
using TEMPLATE_RECORD. 
 
Relnote: "Fixed preview freeze issue when using ImageAnalysis with another stream that uses TEMPLATE_RECORD on Samsung SM-M556B device." 
 
Bug: 395822788 
Test: manual test and ./gradlew bOS 
Change-Id: Ic1a6a019c1525f30d7b863f732d421e36e5c978c

Files:

A camera/camera-camera2-pipe-integration/src/main/java/androidx/camera/camera2/pipe/integration/compat/quirk/AbnormalStreamWhenImageAnalysisBindWithTemplateRecordQuirk.kt
M camera/camera-camera2-pipe-integration/src/main/java/androidx/camera/camera2/pipe/integration/compat/quirk/CameraQuirks.kt
M camera/camera-camera2-pipe-integration/src/main/java/androidx/camera/camera2/pipe/integration/compat/workaround/TemplateParamsOverride.kt
A camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/compat/quirk/AbnormalStreamWhenImageAnalysisBindWithTemplateRecordQuirk.java
M camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/compat/quirk/CameraQuirks.java
M camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/compat/workaround/TemplateParamsOverride.java

Hash: 5b6e8ca646e994efd623332cfe36445ef09d3c23
Date: Mon Mar 10 13:00:18 2025

ja...@gmail.com <ja...@gmail.com> #13Oct 21, 2024 10:30AM

Hey,
I took a look at the fix and I guess it might be a slight problem with it. It only fixes "SM-M556B" but we are positive that the problem also exists for "SM-M556E".

Message last modified on Oct 21, 2024 10:31AM

dc...@openai.com <dc...@openai.com> #14Oct 30, 2024 08:07PM

Thank you for catching this, I will make a change for this.

du...@gmail.com <du...@gmail.com> #15Nov 14, 2024 05:46AM

Project: platform/frameworks/support
Branch: androidx-main
Author: mingdatsai <mingdatsai@google.com>
Link: https://android-review.googlesource.com/3538342

Apply AbnormalStreamWhenImageAnalysisBindWithTemplateRecordQuirk for other M55 models

Expand for full commit details

Apply AbnormalStreamWhenImageAnalysisBindWithTemplateRecordQuirk for other M55 models 
 
Bug: 395822788 
Test: manual test and ./gradlew bOS 
Change-Id: I1768c199f0a4a62e82c7d75f89af574c3eda8604

Files:

M camera/camera-camera2-pipe-integration/src/main/java/androidx/camera/camera2/pipe/integration/compat/quirk/AbnormalStreamWhenImageAnalysisBindWithTemplateRecordQuirk.kt
M camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/compat/quirk/AbnormalStreamWhenImageAnalysisBindWithTemplateRecordQuirk.java

Hash: 0425e0aeba7e562f6d6f99a8d976355f6d563dae
Date: Wed Mar 12 11:55:49 2025

zh...@google.com <zh...@google.com> #16Dec 11, 2024 08:43PM

Reassigned to zh...@google.com.

Hi,

The fix has been merged. It will be released in the subsequest CameraX version, probably 1.4.2 (also on the current 1.5 branch).

I will close the bug, please feel free to reopen it if there are any issues.

ps...@google.com <ps...@google.com> #17Dec 12, 2024 09:48AM

It does not seem to be limited to a specific API, I see logs on API 10 to 15.

These are the errors I see on Crashlytics on a Pixel 8 Pro (unfortunately I have not been able to reproduce locally):

Fatal Exception: java.io.FileNotFoundException: /data/user/0/com.myapp/files/datastore/tracked apps.preferences_pb: open failed: ENOENT (No such file or directory)
       at libcore.io.IoBridge.open(IoBridge.java:574)
       at java.io.FileInputStream.<init>(FileInputStream.java:179)
       at okio.Okio__JvmOkioKt.source(Okio__JvmOkio.kt:181)
       at okio.Okio.source(Okio.java:1)
       at okio.JvmSystemFileSystem.source(JvmSystemFileSystem.java:96)
       at androidx.datastore.core.okio.OkioReadScope.readData$suspendImpl(OkioStorage.kt:227)
       at androidx.datastore.core.okio.OkioReadScope.readData(OkioStorage.kt:1)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invokeSuspend(StorageConnection.kt:74)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.okio.OkioStorageConnection.readScope(OkioStorage.kt:113)
       at androidx.datastore.core.StorageConnectionKt.readData(StorageConnection.kt:74)
       at androidx.datastore.core.DataStoreImpl.readDataFromFileOrDefault(DataStoreImpl.kt:331)
       at androidx.datastore.core.DataStoreImpl.access$readDataFromFileOrDefault(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invokeSuspend(DataStoreImpl.kt:378)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataOrHandleCorruption(DataStoreImpl.kt:377)
       at androidx.datastore.core.DataStoreImpl.access$readDataOrHandleCorruption(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invokeSuspend(DataStoreImpl.kt:314)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataAndUpdateCache(DataStoreImpl.kt:312)
       at androidx.datastore.core.DataStoreImpl.access$readDataAndUpdateCache(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readState$2.invokeSuspend(DataStoreImpl.kt:234)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
       at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.java:115)
       at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:103)
       at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:584)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)

Caused by android.system.ErrnoException: open failed: ENOENT (No such file or directory)
       at libcore.io.Linux.open(Linux.java)
       at libcore.io.ForwardingOs.open(ForwardingOs.java:563)
       at libcore.io.BlockGuardOs.open(BlockGuardOs.java:274)
       at libcore.io.ForwardingOs.open(ForwardingOs.java:563)
       at android.app.ActivityThread$AndroidOs.open(ActivityThread.java:8591)
       at libcore.io.IoBridge.open(IoBridge.java:560)
       at java.io.FileInputStream.<init>(FileInputStream.java:179)
       at okio.Okio__JvmOkioKt.source(Okio__JvmOkio.kt:181)
       at okio.Okio.source(Okio.java:1)
       at okio.JvmSystemFileSystem.source(JvmSystemFileSystem.java:96)
       at androidx.datastore.core.okio.OkioReadScope.readData$suspendImpl(OkioStorage.kt:227)
       at androidx.datastore.core.okio.OkioReadScope.readData(OkioStorage.kt:1)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invokeSuspend(StorageConnection.kt:74)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.StorageConnectionKt$readData$2.invoke(StorageConnection.kt:20)
       at androidx.datastore.core.okio.OkioStorageConnection.readScope(OkioStorage.kt:113)
       at androidx.datastore.core.StorageConnectionKt.readData(StorageConnection.kt:74)
       at androidx.datastore.core.DataStoreImpl.readDataFromFileOrDefault(DataStoreImpl.kt:331)
       at androidx.datastore.core.DataStoreImpl.access$readDataFromFileOrDefault(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invokeSuspend(DataStoreImpl.kt:378)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataOrHandleCorruption$2.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataOrHandleCorruption(DataStoreImpl.kt:377)
       at androidx.datastore.core.DataStoreImpl.access$readDataOrHandleCorruption(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invokeSuspend(DataStoreImpl.kt:314)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.DataStoreImpl$readDataAndUpdateCache$4.invoke(DataStoreImpl.kt:16)
       at androidx.datastore.core.SingleProcessCoordinator.tryLock(SingleProcessCoordinator.kt:50)
       at androidx.datastore.core.DataStoreImpl.readDataAndUpdateCache(DataStoreImpl.kt:312)
       at androidx.datastore.core.DataStoreImpl.access$readDataAndUpdateCache(DataStoreImpl.kt:53)
       at androidx.datastore.core.DataStoreImpl$readState$2.invokeSuspend(DataStoreImpl.kt:234)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
       at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.java:115)
       at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:103)
       at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:584)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
       at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)

ma...@marcardar.com <ma...@marcardar.com> #18Jan 13, 2025 12:42PM

I've also been seeing this since updating from 1.0.0 (problem exists in both 1.1.0 and 1.1.1) and so I had to downgrade to 1.0.0 to avoid these crashes.

Has anyone tried: https://developer.android.com/topic/libraries/architecture/datastore?hl=en#handle-file-corruption ? Does it help?

UPDATE: no it doesn't help

Message last modified on Jan 15, 2025 10:46AM

ma...@marcardar.com <ma...@marcardar.com> #19Jan 15, 2025 10:48AM

Comment has been deleted.

Message last modified on Jan 16, 2025 03:50PM

ni...@usecopper.com <ni...@usecopper.com> #20Jan 21, 2025 02:47PM

having the same issue. Seeing that there is no solution yet, as a temporary test fix, we're considering making a dummy DataStore call immediately at the app startup and catching the exception

in...@gmail.com <in...@gmail.com> #21Feb 7, 2025 01:53PM

Also, had the same issue using it in the compose multiplatform project with datastore library of version "1.1.1"

el...@google.com <el...@google.com> Feb 14, 2025 07:28AM

Reassigned to el...@google.com.

el...@google.com <el...@google.com> #22Feb 15, 2025 02:59AM

Hi there - we were able to reproduce the issue on our end, a fix is in the works. I'll update here once we have it merged & ready for release.

el...@google.com <el...@google.com> #23Feb 19, 2025 12:00AM

Marked as fixed.

This issue should be fixed for the upcoming 1.1.3 release. Please let us know if the issue persists after the release.

ap...@google.com <ap...@google.com> #24Feb 19, 2025 12:02AM

Project: platform/frameworks/support
Branch: androidx-main
Author: elifbilgin <elifbilgin@google.com>
Link: https://android-review.googlesource.com/3496412

Resolve FileNotFoundException issue in OkioStorage at startup.

Expand for full commit details

Resolve FileNotFoundException issue in OkioStorage at startup. 
 
This change introduces a second attempt at reading a file in OkioStorage `readData()`, in case the initial read attempt failed due to a race condition caused by in the file being created by a different process. 
 
Bug: 337870543 
Test: Tested locally via aosp/3496411. 
Change-Id: I43b3fb565cc76344bc14c7dc3964ff76b2319358

Files:

M datastore/datastore-core-okio/src/commonMain/kotlin/androidx/datastore/core/okio/OkioStorage.kt
A datastore/datastore-core-okio/src/commonTest/kotlin/androidx/datastore/core/okio/OkioFakeFileSystem.kt
M datastore/datastore-core-okio/src/commonTest/kotlin/androidx/datastore/core/okio/OkioStorageTest.kt
M datastore/datastore-core/src/jvmAndroidMain/kotlin/androidx/datastore/core/FileStorage.kt

Hash: 3e2cc72ab89a0c011f99627a61eba045d7378cb5
Date: Thu Feb 13 23:25:56 2025

ki...@protonmail.com <ki...@protonmail.com> #25Feb 24, 2025 07:14PM

still present in 1.1.2

only present on Android/JVM no problem on iOS

Message last modified on Feb 24, 2025 07:16PM

el...@google.com <el...@google.com> #26Feb 24, 2025 07:29PM

Thanks for the update regarding the platform specific behavior, we are still working on pinpointing the issue

el...@google.com <el...@google.com> #27Feb 24, 2025 07:32PM

kikoski@protonmail.com Could you share some info on how you are initializing/setting up your datastore?

el...@google.com <el...@google.com> #28Feb 25, 2025 12:22AM

Apologies, this issue is resolved and the fix will be available in 1.1.3

Issue 337870543

Description

Issue summary

Comments

mk...@opera.com <mk...@opera.com> #2Apr 30, 2024 07:37AM

se...@opera.com <se...@opera.com> #3May 8, 2024 09:17AM

to...@gmail.com <to...@gmail.com> #4May 27, 2024 12:41PM

mk...@opera.com <mk...@opera.com> #5Jun 13, 2024 11:35AM

di...@gmail.com <di...@gmail.com> #6Jul 1, 2024 09:02AM

da...@asana.com <da...@asana.com> #7Jul 12, 2024 12:20AM

mi...@outlook.com <mi...@outlook.com> #8Jul 17, 2024 07:35PM

ju...@ratpsmartsystems.com <ju...@ratpsmartsystems.com> #9Jul 18, 2024 01:06PM

br...@linear.app <br...@linear.app> #10Aug 19, 2024 06:18PM

mk...@opera.com <mk...@opera.com> #11Aug 19, 2024 06:54PM

dc...@openai.com <dc...@openai.com> #12Sep 23, 2024 10:58PM

ja...@gmail.com <ja...@gmail.com> #13Oct 21, 2024 10:30AM

dc...@openai.com <dc...@openai.com> #14Oct 30, 2024 08:07PM

du...@gmail.com <du...@gmail.com> #15Nov 14, 2024 05:46AM

zh...@google.com <zh...@google.com> #16Dec 11, 2024 08:43PM

ps...@google.com <ps...@google.com> #17Dec 12, 2024 09:48AM

ma...@marcardar.com <ma...@marcardar.com> #18Jan 13, 2025 12:42PM

ma...@marcardar.com <ma...@marcardar.com> #19Jan 15, 2025 10:48AM

ni...@usecopper.com <ni...@usecopper.com> #20Jan 21, 2025 02:47PM

in...@gmail.com <in...@gmail.com> #21Feb 7, 2025 01:53PM

el...@google.com <el...@google.com> Feb 14, 2025 07:28AM

el...@google.com <el...@google.com> #22Feb 15, 2025 02:59AM

el...@google.com <el...@google.com> #23Feb 19, 2025 12:00AM

ap...@google.com <ap...@google.com> #24Feb 19, 2025 12:02AM

ki...@protonmail.com <ki...@protonmail.com> #25Feb 24, 2025 07:14PM

el...@google.com <el...@google.com> #26Feb 24, 2025 07:29PM

el...@google.com <el...@google.com> #27Feb 24, 2025 07:32PM

el...@google.com <el...@google.com> #28Feb 25, 2025 12:22AM

Add comment

Issue metadata