fix: register the Lua game-mode providers at application start - #343
Merged
Conversation
#333 inverted mode resolution so asobi_game_modes resolves {lua, Script} through a provider registry instead of hardcoded asobi_lua_* atoms, and returns lua_runtime_unavailable when a kind has no provider. The writer was asobi_lua's own application-start callback. #339 then merged the Lua runtime into asobi and removed that application without moving the registration, so nothing ever populated the registry: every Lua mode resolved to lua_runtime_unavailable. Both PRs were green on their own base and red together, which is why main went red on merge. Register from asobi_app:start/2, ahead of the supervision tree so the matchmaker cannot observe an empty registry. The mapping itself lives in asobi_lua_sup next to the bridges, so asobi_game_modes still knows nothing about the scripting runtime, and tests that resolve a lua mode without booting the application call the same function. asobi_lua_config_tests now registers in its fixture and unregisters in teardown; asobi_game_modes_tests:lua_without_provider establishes the absence it asserts on rather than inheriting it from module order.
… hits #337 wrapped the match-result write in asobi_repo:transaction/1 so the match record and the player_stats bump land together. #339 brought asobi_lua_SUITE across from the asobi_lua repo, where it mocks asobi_repo strictly and stubs only insert/1,2. Together, the finish path calls asobi_repo:transaction/1 on a strict mock that has no such function, the call is undef, the match server dies mid-finish, and the suite reports match_did_not_finish - naming the symptom and not the cause. Two tests, on main and on every branch cut from it. The suite runs without a repo pool, so transaction/1 runs the fun inline rather than passthrough reaching for a database that is not there. record_match/2 is stubbed too: stats persistence has its own tests and this suite is the Lua match lifecycle.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Main is red. #333 and #339 were each green on their own base and broke each other on merge.
#333 replaced the hardcoded
asobi_lua_*atoms inasobi_game_modeswith a provider registry, returninglua_runtime_unavailablefor a kind with no provider. The writer was asobi_lua's application-start callback.#339 merged the Lua runtime into asobi and removed that application without carrying the registration across, so the registry was never populated and every
{lua, _}mode resolved tolua_runtime_unavailable. Sixasobi_lua_config_testscases fail on main.Registration now happens in
asobi_app:start/2, before the supervision tree, so no child (the matchmaker in particular) can observe an empty registry. The mapping lives inasobi_lua_sup:register_game_modes/0next to the bridge modules, keepingasobi_game_modesignorant of the scripting runtime, and giving tests that resolve a Lua mode without booting the app one function to call.Tests
asobi_lua_sup_testspins all three registrations and their idempotency, so a future refactor that drops one fails here rather than at runtime.asobi_lua_config_testsregisters in its fixture and unregisters in teardown.asobi_game_modes_tests:lua_without_providernow establishes the absence it asserts on; the registry is a globalpersistent_term, so it was inheriting its result from module order.Local: eunit 1030/1030, xref, dialyzer and
fmt --checkall clean.