Skip to content

Conversation

@brandonpayton
Copy link
Member

Motivation for the change, related issues

We have automated tests for our file lock manager but no integration tests to demonstrate locking is working between @php-wasm/node instances. Let's fix that.

Implementation details

This PR adds automated tests for file locking within @php-wasm/node. It coordinates between two or more concurrent @php-wasm instances using a simple text file to gate the stages. For example, for php instances php1 and php2 testing exclusive locking:

  • File initially contains "php1-locking"
  • php1 starts without waiting
  • php2 waits until file contains "php1-waiting-for-php2-to-try"
  • php1 obtains an exclusive lock on a SQLite DB and sets file contents to "php1-waiting-for-php2-to-try"
  • php1 waits until file contains "php2-ready-for-unlock"
  • php2 attempts to write to DB, records the outcome, and sets file contents to "php2-ready-for-unlock"
  • php2 waits until file contains "php1-unlocked"
  • php1 unlocks the DB, sets file contents to "php1-unlocked", and exits
  • php2 repeats its attempt to right the DB, records the outcome, echoes its results, and exits
  • the test case asserts expected outcome

Maybe there is a better way to coordinate between instances, but so far, this seemed the most straightforward.

Once these tests are fleshed out, we can probably add nearly identical tests for Playground CLI, but run the scripts via HTTP requests.

Testing Instructions (or ideally a Blueprint)

  • CI

@brandonpayton brandonpayton requested a review from a team November 16, 2025 07:28
@brandonpayton brandonpayton self-assigned this Nov 16, 2025
@brandonpayton
Copy link
Member Author

brandonpayton commented Nov 17, 2025

I had Claude try to fill in the remaining outlined tests. I haven't reviewed or refined the results yet, but one of the failing tests was for a real reason:

flock() locks are not currently released when their associated file descriptor is closed. This is a bug, and I've pushed a fix. But the php-wasm/node rebuild will have to complete overnight. (Note: A rebuild wouldn't be required here if we manage to land something like #2891 to move our Emscripten syscall customization into separate modules that are injected at runtime)

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants