search

ytgov / travel-authorization

0 stars 3 forks source link

Travel Auth: Generate estimate error #97

Open dpdavids opened 3 weeks ago

dpdavids commented 3 weeks ago

Describe the BUG On Generate estimates get the following error "Travel authorization update failed: Error: Could not update TravelAuthorization: SequelizeForeignKeyConstraintError: insert or update on table "travel_authorizations" violates foreign key constraint "travel_authorizations_purpose_id_foreign""

To Reproduce Steps to reproduce the behavior:

  1. Click add new travel
  2. fill out fields (see screen capture)
  3. select generate estimates
  4. get errors

Expected behavior Estimates generated.

Screenshots image image

Desktop (please complete the following information):

dpdavids commented 3 weeks ago

I deleted the above request and tried a similar request that previously worked. I get the same error occurs.

klondikemarlen commented 3 weeks ago

Sounds like the "Purpose" field isn't propagating correctly to the back-end. Either because its not a required field (and should be), or because its not propagating correctly after its selected.

klondikemarlen commented 2 weeks ago

I can't recreate, so I'm thinking this is a caching bug? I might need you (@dpdavids) to recreate this while I'm watching the logs to see what what's happening.

I note that the purpose selector on the page (web/src/modules/travel-authorizations/components/edit-my-travel-authorization-details-page/PurposeFormCard.vue) is using a legacy pattern and should be using web/src/components/TravelPurposeSelect.vue.

dpdavids commented 2 weeks ago

@klondikemarlen I can seem to regenerate this error now. Did you want to keep this as a note to update from the legacy pattern to the new one? or should we close this and create a new item?

klondikemarlen commented 2 weeks ago

I'd say close it for now, and if this happens again, create a cleanup ticket, and link this bug as a reference. After cleanup, if it still re-occurs we can invest more effort in recreating. Also, if you can, give a time of day estimate for when the error occurred we can try to dig it out of the logs. (we have persistent logs now, though only going back 1 month)

As the app stands, it's quite large, so we can expect these kinds of (flakiness) issues to pop up more frequently. In past projects, I've seen this kind of thing handled via a "triage" process where we look at the logs, and see how often it occurs, and how severely it effects users, before moving to investigate further.

Infrequent flaky behaviour is usually something that gets fixed in production, when enough users complain.