3 ms·
If I understand correctly, both the staging database and the production database share the same volume. Thus, production data was gone as well after deleting th
by throwdbaaway 5mo ago
If I understand correctly, both the staging database and the production database share the same volume. Thus, production data was gone as well after deleting the volume.
1st hint - the API call only contains one volume:
curl -X POST https://backboard.railway.app/graphql/v2 \
-H "Authorization: Bearer [token]" \
-d '{"query":"mutation { volumeDelete(volumeId: \"3d2c42fb-...\") }"}'
2nd hint - this gem from the tweet:
> No "this volume contains production data, are you sure?"
- hunterpayne 5mo ago"If I understand correctly, " You don't. You are missing the part where the LLM had a token which blocked access as expected. Then the LLM searched the source base, found a different token with the delete privs and then used that. PS That warning happens in staging envs too, the LLM doesn't know which env is which by design.
- throwdbaaway 5mo agoHuh that's not what I gathered from the tweet at all. If I am going to write a five why's analysis, the immediate cause is the LLM wrongly decided to delete a volume, while the root cause is the bad design to co-locate staging and production data in the same volume. The writing was quite vague though, let's wait for a response from railway.