Repository navigation
fail loudly when the app package has no __init__.py - #7304
Conversation
|
There was a problem hiding this comment.
All reported issues were addressed across 3 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
Merging this PR will not alter performance
Comparing Footnotes
|
|
Updated this to create the missing |
There was a problem hiding this comment.
All reported issues were addressed across 3 files (changes from recent commits).
You’re at about 90% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
There was a problem hiding this comment.
All reported issues were addressed across 2 files (changes from recent commits).
You’re at about 90% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
FarhanAliRaza
left a comment
There was a problem hiding this comment.
I tested this PR with a small app. The app has a root state and a substate, and its app package has no __init__.py.
On the base commit, I reproduced #7258. Clicks did not update the page, and the browser console showed the no dispatch function for substate(s) error.
On this branch, the bug is fixed in dev mode and in prod mode. The backend created the missing __init__.py in the app source tree and did not log a message.
I then changed only the Granian target on the base commit to the module name. That change also fixed the bug, and it wrote no file. Hot reload and the existing tests still passed.
The requested change is in the inline comment.
There was a problem hiding this comment.
All reported issues were addressed across 4 files (changes from recent commits).
You’re at about 91% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.
Requires human review: Auto-approval blocked because this review re-detected 1 unresolved issue already reported by Cubic.
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
There was a problem hiding this comment.
All reported issues were addressed across 2 files (changes from recent commits).
You’re at about 91% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
#7304 ended up passing Granian the configured module target, so the original fragment was accurate. The start method variables are only read on the Granian code paths. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016T8wWv8bUUSzRHNGpKbSqW
#7646) * Correct 0.10.1 news fragments and document REFLEX_BACKEND_START_METHOD The 7258 fragment described the opposite of what #7304 does (it raises an error for a missing __init__.py instead of loading the app), the repeated headers fragment still claimed client_ip came from the first x-forwarded-for hop after #7614 made that depend on trusted_proxy_hops, and the 7261 fragment belonged to a docs-only change. Add the backend start method variables to the self-hosting docs; they were only described in environment.py. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016T8wWv8bUUSzRHNGpKbSqW * Keep the 7258 fragment and scope the start method docs to Granian #7304 ended up passing Granian the configured module target, so the original fragment was accurate. The start method variables are only read on the Granian code paths. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016T8wWv8bUUSzRHNGpKbSqW --------- Co-authored-by: Claude <noreply@anthropic.com>
Fixes #7258
The granian backend gets the app as a file path, and granian works out the module name by walking up through directories that have an
__init__.py. Whenmyapp/myapp/__init__.pyis missing it imports the app asmyappinstead ofmyapp.myapp. The compiler usedmyapp.myapp, so the root state names don't match and every delta gets dropped on the client.get_app_file()now checks that each package in the app module path has an__init__.pyand raises a clear error pointing at the missing file, instead of starting a backend that looks fine but never updates.Tests cover the missing-init layouts (including a package-style
app_module_import) and check that granian resolves the app file to the configured module name for valid layouts. Ran the unit suite, ruff, and pyright on the touched packages locally (full-repo pyright ran out of memory on my machine).