-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DataStore] ReferenceError: Property 'err' doesn't exist #12824
Comments
It happens during this LOG 2024-01-10 15:40:35.448+02:00 [DATASTORE / ApplicationStack_Synced] DataStore event received:
LOG {
"event": "outboxStatus",
"data": {
"isEmpty": false
}
} |
Update: The error I report below, we now believe may be a separate DataStore bug. So read the following accordingly. A bit more information on this as I'm working with @dmitryusikriseapps on this: When I attempt to save a model type ( When I tried to use the app to update a Worker's name twice in fairly quick succession, in my testing I couldn't recreate the error above that way. However when I updated the code to make two back to back
For reference, I updated our code to do: let updatedWorker = await DataStore.save(
DataStoreModels.Worker.copyOf(remoteWorker, updated => { ... })
);
// Duplicate the update here to show the error:
updatedWorker = await DataStore.save(
DataStoreModels.Worker.copyOf(remoteWorker, updated => { ... })
); Interestingly if I add a sleep in between the two const sleep = (ms: number): Promise<void> => {
return new Promise(resolve => {
setTimeout(resolve, ms);
});
};
log(`updateCurrentWorker(): Saving to DataStore`);
let updatedWorker = await DataStore.save(
DataStoreModels.Worker.copyOf(remoteWorker, updated => { ... })
);
await sleep(15000);
log(`updateCurrentWorker(): Saving to DataStore`);
updatedWorker = await DataStore.save(
DataStoreModels.Worker.copyOf(remoteWorker, updated => { ... })
); Perhaps importantly I can confirm that the DataStore outbox is evented as empty before the 2nd mutation and we still get the problem, so it doesn't seem related to that at least.
I am hopeful this error is quite reproducible on your end, but next step is I'm going to check the AppSync logs in CloudWatch and I'll report back on anything interesting I find there. |
Looking more into my error directly above, I think it's a separate issue to the one @dmitryusikriseapps reported, but a bug in its own right that I'd like to see fixed. Regarding the original I'm wondering if this issue is related to the React Native environment, and the Hermes engine in particular, as some initial searching indicates it may be. Here is the where the error is coming from:
Not being able to reference We'll try and provide as simple a problem recreate as possible, as we'd really like to see any bug identified fixed, as this is totally blocking our migration to v6. |
@chrisbonifacio I've spent quite a bit of time trying to narrow down the problem recreation scenario to help recreate this bug in as simple as manner possible. What I found is I could reliably recreate both the Note: I recreated this in a React Native application, and the former error in particular may only be recreatable there, I'm not sure. I am hopeful the instructions below should allow you or others on the team (perhaps @iartemiev ?) to recreate these too with minimal effort. Both @dmitryusikriseapps and I are happy to help as currently this bug(s) is blocking us from migrating to v6 and we'd really like to do that. Problem Recreation ScenariosThe code below works on a simple
These two scenarios are then repeated but a 5 second sleep is added between the two DataStore mutation operations above. This gives 4 different scenaros so far. Finally, I noticed that adding a Pipeline Resolver for the This leads to 8 total test scenarios that I've tested and documented my findings. Problem Recreation Codeconst sleep = (ms: number): Promise<void> => {
return new Promise(resolve => {
setTimeout(resolve, ms);
});
};
let jobInfo = (await DataStore.query(DataStoreModels.ContractorJobInfo, info => info.jobId.eq('dummy-id')))[0];
if (jobInfo == null) {
console.log(`Creating ContractorJobInfo`);
jobInfo = await DataStore.save(
new DataStoreModels.ContractorJobInfo({
contractorId: currentContractor.id,
cognitoUserId: currentContractor.cognitoUserId,
jobId: 'dummy-id',
})
);
} else {
console.log(`Updating ContractorJobInfo initially`);
jobInfo = await DataStore.save(
DataStoreModels.ContractorJobInfo.copyOf(jobInfo, updated => {
updated.contractorId = `changed-${dayjs().toISOString()}`;
})
);
}
// Some of the test scenarios sleep between DataStore operations, others don't
// This is to see how adding a delay (for outbox syncing) affects things
// await sleep(5000);
console.log(`Updating ContractorJobInfo`);
await DataStore.save(
DataStoreModels.ContractorJobInfo.copyOf(jobInfo, updated => {
updated.contractorId = 'overwritten';
})
); Pipeline ResolversAs I mentioned above we have some additional custom PipelineResolvers for
|
Problem Recreation ResultsBased on the code above and 8 different test scenarios I've described, I can consistently recreate both the Though I'll state immediately that I could only recreate the So we'll start when custom Pipeline Resolvers are active: 1. With Custom Pipeline Resolvers ActiveNote: The custom pipeline resolver must modify the data for it to recreate the results below. 1.1 With no
|
Problem SummaryFrom my problem recreation scenarios and results above, I observed a few things.
That complicated the problem recreation steps, so for my recreation scenarios above I just used one model type, but it may be worth noting as it seems a Custom Pipeline resolver modifying data on the first mutation is ultimately what causes the 2nd mutation to fail with Next StepsI've tried to provide as much information as I can in order for you to recreate these problems simply and reliably. They seem high priority to me given the errors. Certainly we cannot migrate to v6 until they are fixed. If you can't recreate them, both @dmitryusikriseapps and I are happy to assist. You may need to test in a React Native environment to recreate some of these issues. We use Expo, and we had to build a custom Development Client through Expo to test with because v6 of the Amplify libraries aren't natively linked in Expo Go (see this Expo discussion: expo/expo/discussions/25586). I'm hopeful experienced AWS DataStore developers such as @chrisbonifacio and @iartemiev can easily recreate this issue and then look for the root cause. That is where our experience really runs dry, but we're happy to assist as we can. |
Hi @danrivett! Thank you for taking the time to deep dive into the issues you're experiencing and sharing your findings. I don't have an update just yet, but wanted to let you know we will be looking into it and what you've shared so far helps a ton! |
@chrisbonifacio it seems like your team has been very busy with other initiatives (gen 2 etc) so I've avoided asking for updates up until now to give some space and time whilst your team is working on other things, but this is still blocking my team from upgrading to v6, and so is becoming higher in priority for us. Is there anything we can do to assist in troubleshooting or investigating this, as we'd really love to see this investigated and any necessary fixes made. |
I'd definitely appreciate an update from AWS of some sort. The radio silence is really disconcerting, as it's a blocker for us to migrate to v6. We're willing to assist in recreation and root cause analysis if needed, but we can't solve the problem entirely on our own, and hope AWS Support will engage to assist in resolving this. |
I'm not sure who's leading Amplify DataStore support, but I'm very happy to work directly with them either through this ticket or preferably through an AWS Chime meeting to discuss and work out a plan of attack. |
@chrisbonifacio given all the focus on Gen 2, and the fact DataStore seems unlikely to be supported there, I can somewhat understand why this bug report doesn't appear to have been worked on since I raised it in January. We've been holding off upgrading to Gen 1 v6 libraries because this is a blocker as breaks our application, and like I mentioned in September, I'd be more than happy to work with anyone on AWS' side to move this ticket forward. We currently use DataStore extensively both in a React Native application as well as a Next.js web application, and any migration off of DataStore as part of a wider Gen 2 migration is likely to be quite a way down the road given all the moving pieces required to do that, and the fact we're not sure how different the proposed DataStore replacement (React-Query + Offline Persistence plugin?) will be to integrate. So if there is anyone still looking after DataStore that is willing to investigate this bug (including when pipeline resolvers mutate the data too - see writeup above), we'd be thrilled and very happy to assist if helpful. /cc @undefobj just for his awareness as I know he worked extensively on the initial design and implementation of DataStore so may have some thoughts. |
Hi @danrivett & @dmitryusikriseapps, apologies for the delay on this issue. I ran into some issues early on reproducing the issue and it fell off our radar but we are picking it up back to try and reproduce again with the new information provided. We will report back once we've reproduced and identified the root cause. So far, after some trial and error I've got an Expo app ready to start adding the code snippets provided. From the scenarios listed in your previous comments it seems there are two errors and which one occurs depends on whether or not custom pipeline resolvers are active or not. I think the only info missing might be the schema of the In the meantime, thank you for your patience while we try to get this fixed. |
Update: based on the provided information, I've inferred this to be the schema to try and move forward with the reproduction of the issue and make use of the pipeline resolvers. Please correct if wrong! type ContractorJobInfo @model @auth(rules: [{ allow: private }]) {
id: ID!
contractorId: String!
cognitoUserId: String!
jobId: String!
createdBy: String
lastEdited: LastEdited
}
type LastEdited {
cognitoUserId: String!
at: AWSDateTime!
versionEdited: Int!
} |
Update: I've got the app "working" so far on v6. When I attempt to create and/or update a record, I am not seeing an error yet but I am observing that the record is not being updated with values from the server such as Here is the app I'm using to attempt to reproduce the issue: https://github.com/chrisbonifacio/amplify-issue-12824 I'm not seeing errors in the console but perhaps they're appearing in the network logs or cloudwatch logs? |
Hi @chrisbonifacio thanks so much for your reply and taking time today to work on this. Ironically I'm travelling with work currently so I've only just had time to read through your updates. Before I posted the update request earlier this week, I asked one of the developers on our team to verify the issue was still present in our app, which they confirmed. So I'm going to first reverify this myself with any helpful details I find, and then download your repo and try and recreate it there. I'll post back as soon as I have those results. Thanks again for taking time on this, I'm sure we'll be able to make some rapid progress between the two of us. |
And just to confirm, we saw DataStore errors in the React Native log, but I can't remember what I saw in the AppSync CloudWatch logs, so I'll have to update you on that once I recreate it again now. |
A quick update for the end of the week: I spent a few hours recreating the issue in various builds of our app over the last 6 months, and I can recreate it using the scenario above in all builds, both Expo 48 and Expo 50 which we're currently on, and both on the We're not on Expo 51 yet as we're waiting for Expo 52 since it should be out pretty soon. Interestingly although we see the error (technically it's a warning) on the latest build (Expo 50 and For reference this is what I see in the simulator: I need to dig further next week once I'm back from my trip, as I'll more easily be able to try and recreate using your repo too. It was a bit tricky for me to do that today as I also need to deploy a new Amplify BE for it and that's easier for me to do next week. So more to come, but I just wanted to at least provide an update with what I found today. |
Just a brief update to say @dmitryusikriseapps and I have been making good progress understanding the errors we're seeing, and during digging and temporarily patching Amplify libraries locally to log more things out and get past things, we've uncovered a couple of bugs on our end that doesn't currently get surfaced by DataStore so we didn't know about. We also think there are possibly a couple of bugs in the Amplify library too. I'll write up once we've double checked and can summarise things best for review by you and your colleagues Chris. So expect that summary later this week, and then you can review and see if they are able to be fixed. |
Hi @danrivett Were you able to gather the details of the issues? And was the repo I provided helpful? |
@chrisbonifacio Sorry for the delay. I've been delaying writing up the results as trying to make it as clear as possible. The main issue in this ticket That The other main issue we had was We also found one other bug where DataStore wasn't handling an error response returned by an AppSync Mutation because We're currently running through further regression testing after fixing the issues it uncovered on our end, and then I'll add final details for you to review. But bottom line is if others run into |
Before opening, please confirm:
JavaScript Framework
React Native
Amplify APIs
Authentication, DataStore, Storage
Amplify Version
v6
Amplify Categories
auth, storage, api
Backend
None
Environment information
Describe the bug
As soon as some
DataStore
mutations are called with a break near 1-2 seconds between them, then an unhandled promise is thrown. Then if the application is reloaded, the warning will still be shown. If the current user is signed out and authenticated one more time, then an uncaught error will be thrown. Everything was working well using the 5th version of the aws-amplify library.Expected behavior
No warnings or errors should be thrown.
Reproduction steps
Code Snippet
// Put your code below this line.
Log output
aws-exports.js
No response
Manual configuration
No response
Additional configuration
No response
Mobile Device
iPhone 15 Plus
Mobile Operating System
iOS 17.0
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
No response
The text was updated successfully, but these errors were encountered: