test: add env ATUIN_TEST_LOCAL_TIMEOUT to control test timeout of SQLite

[jaxvanyang]

This make it possible to control the timeout of SQLite operations in test. And ATUIN_TEST_LOCAL_TIMEOUT defaults to the default local_timeout, which is actually used in the client. Instead of a small timeout (0.1), this change makes the test less likely to fail and better imitate the default behavior.

SQLite operation timeout was first introduced from #1590, including connection and store timeout. The env ATUIN_TEST_SQLITE_STORE_TIMEOUT which added by #1703 only specify the store timeout. This commit doesn't deprecate ATUIN_TEST_SQLITE_STORE_TIMEOUT, but control it by setting its default to the new env ATUIN_TEST_LOCAL_TIMEOUT.

The reason is the same as #1703, but this time it fails due to connection timeout: archriscv.felixc.at/.status/log.htm?url=logs/atuin/atuin-18.3.0-1.log.

And I have two question for this commit if it's acceptable:

• Should we replace the old ATUIN_TEST_SQLITE_STORE_TIMEOUT with the new ATUIN_TEST_LOCAL_TIMEOUT for simplicity?
• Is there a simple way to get the local_timeout value? Using Settings::builder() seems complex.

Checks

• [x] I am happy for maintainers to push small adjustments to this PR, to speed up the review cycle
• [x] I have checked that there are no existing pull requests for the same thing

[ellie]

Should we replace the old ATUIN_TEST_SQLITE_STORE_TIMEOUT with the new ATUIN_TEST_LOCAL_TIMEOUT for simplicity?

That would be good!

Is there a simple way to get the local_timeout value? Using Settings::builder() seems complex.

Not really. The builder is complex because the setting could come from multiple sources - env, config file, others in the future. I'd like to overhaul it a bit at some point though

Otherwise, how does SQLite tend to perform on RISC? Totally cool with this change, but I'm just wondering if reads are always going to take >100ms even for simple cases

[jaxvanyang]

Should we replace the old ATUIN_TEST_SQLITE_STORE_TIMEOUT with the new ATUIN_TEST_LOCAL_TIMEOUT for simplicity?

That would be good!

OK, I'll push another commit for that.

Otherwise, how does SQLite tend to perform on RISC? Totally cool with this change, but I'm just wondering if reads are always going to take >100ms even for simple cases

Short answer: not always. RISC-V is just an ISA, performance is more related to silicon technology. AFAIK, RISC-V is at its early stage, most companies focus on embedded system, providing SBCs for testing. These devices are not powerful. And Arch Linux RISC-V is just a personal port project, although it's sponsored, I think its builder machines have limited performance, I think they are using QEMU for some builds, it may cause some performance problem as well. If you are interested in current performance status of RISC-V, you can find some articles on Phoronix, e.g., Benchmarking The First RISC-V Cloud Server: Scaleway EM-RV1 Performance - Phoronix.

[jaxvanyang]

thank you 🙏

Seeing as this is your first time contributing, if you would like a holographic contributors-only Atuin sticker, then please fill out this form!

We do also have a Discord if you'd like to ask any questions, or just fancy hanging out!

Glad to hear that, thank you.