Skip to content
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

[CouchDB] Modifying search input sometimes causes conflict errors #7275

Closed
2 of 7 tasks
ozyx opened this issue Dec 5, 2023 · 2 comments · Fixed by #7276
Closed
2 of 7 tasks

[CouchDB] Modifying search input sometimes causes conflict errors #7275

ozyx opened this issue Dec 5, 2023 · 2 comments · Fixed by #7276
Labels
type:bug verified Tested or intentionally closed
Milestone

Comments

@ozyx
Copy link
Contributor

ozyx commented Dec 5, 2023

Summary

When deleting characters in a search query while using CouchDB, sometimes a conflict error can be seen in the network tab of a PUT request against 'mine' (My Items folder).

This is caused by the myItemsInterceptor being triggered (this creates the 'My Items' folder if it doesn't already exist on startup) because a domainObject is being returned as undefined from an aborted CouchObjectProvider.get() request.

Expected vs Current Behavior

We should handle the case of aborted requests returning undefined domain objects

Steps to Reproduce

  1. Start Open MCT w/ Couch DB (openmct-quickstart might be good for this)
  2. In the Grand Search, search for something and let the request complete
  3. With the network tab open, one-by-one, remove a letter. Make sure to trigger Aborts by removing it in the middle of requests.
  4. See the conflict error in the console / network tab
  5. If you don't see it, refresh and try again. It's only ever triggered once for some reason.

Environment

  • Open MCT Version: 3.3.0-next
  • Deployment Type: testathon
  • OS: any
  • Browser: any

Impact Check List

  • Data loss or misrepresented data?
  • Regression? Did this used to work or has it always been broken?
  • Is there a workaround available?
  • Does this impact a critical component?
  • Is this just a visual bug with no functional impact?
  • Does this block the execution of e2e tests?
  • Does this have an impact on Performance?

Additional Information

@rukmini-bose
Copy link
Contributor

Verified Testathon 12/12/23, tried reproducing this many times and haven't been able to get any conflict errors in the console

@charlesh88
Copy link
Contributor

Testathon 2023-12-12 verified fixed. Abort errors are reported, but no conflict errors.

image

@ozyx ozyx added the verified Tested or intentionally closed label Jan 17, 2024
@unlikelyzero unlikelyzero modified the milestones: Target:3.3.0, Target:4.0.0 Feb 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug verified Tested or intentionally closed
Projects
None yet
5 participants