Make flowmachine table cache owner

[greenape]

Closes #4714

I have:

• Formatted any Python files with black
• Brought the branch up to date with master
• Added any relevant Github labels
• Added tests for any new additions
• Added or updated any relevant documentation
• Added an Architectural Decision Record (ADR), if appropriate
• Added an MPLv2 License Header if appropriate
• Updated the Changelog

Description

1. Makes the flowmachine user always named flowmachine (you can create other users, but there shall always be a flowmachine user
2. Adds, as a post action on writing to cache, an ownership change of the newly created table to flowmachine.

[codecov]

Codecov Report

Merging #5189 (2d7d2c1) into master (2ea7f5c) will decrease coverage by 0.00%.
The diff coverage is 96.29%.

@@            Coverage Diff             @@
##           master    #5189      +/-   ##
==========================================
- Coverage   93.93%   93.93%   -0.01%     
==========================================
  Files         276      276              
  Lines       10640    10646       +6     
  Branches     1271     1274       +3     
==========================================
+ Hits         9995    10000       +5     
  Misses        518      518              
- Partials      127      128       +1     

Impacted Files	Coverage Δ
flowmachine/flowmachine/core/cache.py	92.69% <96.15%> (-0.25%)	⬇️
flowmachine/flowmachine/core/query.py	95.94% <100.00%> (+0.01%)	⬆️

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

[cypress]

---

Test summary

43 • 0 • 0 • 0 • 0

---

Run details

Project	FlowAuth
Status	Passed
Commit	2d7d2c1
Started	Jun 20, 2022 11:32 AM
Ended	Jun 20, 2022 11:44 AM
Duration	12:42 💡
OS	Linux Debian - 10.5
Browser	Electron 100

View run in Cypress Dashboard ➡️

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[jc-harrison]

Can also remove the FLOWMACHINE_FLOWDB_USER env from 'development_environment', and the secret from secrets-quickstart.sh.

[jc-harrison]

Presumably this trigger is no longer required?

[greenape]

I've kept it in to allow for the possibility of tables getting created thru routes other than flowmachine that we'd still want to be managed. That said, I'm not sure there's really an eventuality where that arises and they're also in the cache table.

[jc-harrison]

I'm not sure we would necessarily want to change ownership of tables created through routes other than flowmachine, since the ownership change is specifically so that all flowmachine instances can access flowmachine-generated cache tables. Without an obvious situation where this might occur, I think it's just as plausible that we'd want the opposite - that tables created through some unforeseen route should remain owned by the user that created them.

[greenape]

Yeah, I agree.

[greenape]

Can also remove the FLOWMACHINE_FLOWDB_USER env from 'development_environment', and the secret from secrets-quickstart.sh.

Need to keep these, because flowmachine still has a configurable username, it just happens to be flowmachine in these examples. Perhaps we should mandate it to flowmachine in container though?

[jc-harrison]

Can also remove the FLOWMACHINE_FLOWDB_USER env from 'development_environment', and the secret from secrets-quickstart.sh.

Need to keep these, because flowmachine still has a configurable username, it just happens to be flowmachine in these examples. Perhaps we should mandate it to flowmachine in container though?

Ah, I see. I suppose the question is: would we ever want the flowmachine container to use a postgres user other than flowmachine (perhaps, if individual users wanted to spin up their own flowmachine server and API?). In that situation, the flowmachine service would need a different FLOWMACHINE_FLOWDB_PASSWORD as well.

But for a standard deployment I think we'd always want the flowmachine container to use the flowmachine user. Maybe we could set flowmachine as the default in the container but allow overriding via the env?

[jc-harrison]

I've been thinking about the exception-catching business, and whether catching BaseException is the right thing to do here. I wonder whether it's more appropriate to cancel a query on KeyboardInterrupt than to error it, given that an ERRORED query indicates something went wrong when executing the query and it therefore can't be re-run without a manual reset, whereas CANCELLED indicates query execution was stopped but not due to the query itself, and the query can be re-run without manual intervention. So perhaps:

try:
    <run query>
except Exception as exc:
    q_state_machine.raise_error()
    raise exc
finally:
    if not q_state_machine.is_finished_executing:
        q_state_machine.cancel()

(i.e. if the query is still in a blocking state when it should have finished, but no Exception was raised, cancel it).

[jc-harrison]

👍