Skip to content

Conversation

@mukhtaronif
Copy link

…tion

When multiple SQLPage instances start simultaneously in the same directory, they can encounter a race condition during initialization. The create_default_database() function creates a temporary file to test directory writability, then removes it. If multiple instances try to remove the same file concurrently, some panic with 'No such file or directory'.

This commit replaces the .expect() panic with graceful error handling using if let Err(). The writability test has already succeeded by the time we try to remove the file, so whether another instance removed it is irrelevant.

Includes a test that spawns 10 concurrent threads initializing AppConfig to verify no panics occur.

ref #1183

mukhtaronif and others added 3 commits January 11, 2026 18:12
…tion

When multiple SQLPage instances start simultaneously in the same directory,
they can encounter a race condition during initialization. The create_default_database()
function creates a temporary file to test directory writability, then removes it.
If multiple instances try to remove the same file concurrently, some panic with
'No such file or directory'.

This commit replaces the .expect() panic with graceful error handling using
if let Err(). The writability test has already succeeded by the time we try
to remove the file, so whether another instance removed it is irrelevant.

Includes a test that spawns 10 concurrent threads initializing AppConfig
to verify no panics occur.

ref sqlpage#1183
));
std::fs::create_dir_all(&test_dir).unwrap();

env::remove_var("DATABASE_URL");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's safe to just remove this env var like that. We are actually relying on this env var in other tests when running against a non-default db.

@lovasoa
Copy link
Collaborator

lovasoa commented Jan 11, 2026

@mukhtaronif did you actually manage to reproduce the crash with the test ? I tried removing the fix but keeping the test, and it does not catch the problem for me.

@mukhtaronif
Copy link
Author

@mukhtaronif did you actually manage to reproduce the crash with the test ? I tried removing the fix but keeping the test, and it does not catch the problem for me.

No, I wasn't able to reliably reproduce the crash with the test either. I also tried reverting the fix and running the test multiple times, and it consistently passed.

The race condition is timing-dependent and difficult to trigger in a test environment. Even with a barrier to synchronize the threads in the test, the file system operations complete so quickly that the race window is extremely narrow.
The test could still serve as:

  • A regression guard that verifies concurrent initialization doesn't panic (with the fix)
  • Documentation of the expected concurrent usage pattern

@mukhtaronif
Copy link
Author

We have decided to let surveilr set the DATABASE_URL environment variable before calling AppConfig::from_cli(), which prevents SQLPage from calling create_default_database() entirely and avoids triggering the race condition in the first place.

@lovasoa
Copy link
Collaborator

lovasoa commented Jan 12, 2026

ok, let's remove the test altogether then

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants