jacobh2
97a7200c1a
The scraper never read "överlåtbara dagar" from Försäkringskassan. It only visited ansok-och-planera-foraldrapenning#/valjdagar and derived the reserved/transferable split in build_snapshot, assuming transferable days are spent before reserved ones. On real data that gave 49 for the user and 0 for the partner where FK states 129 and 71. The assumption cannot be repaired: reserved-first, transferable-first, proportional and cap-based models were all checked against real figures and none reproduces FK's accounting (reserved-first fits the partner but is 10 days off for the user). FK publishes the real numbers per parent per tier on the min-foraldrapenning page, which the scraper had never visited. - Scrape the "Dagar ni kan föra över" panel after the valjdagar extraction, summing sjukpenningnivå + lägstanivå per parent. The totals are not literals on the page. Parse only direct-child <p> elements: the first group embeds a tooltip with decoy "45 dagar"/"90 dagar" text. - build_snapshot accepts the reported value and derives reserved days from it; the old arithmetic remains only as a fallback. An implausible FK value degrades to that fallback rather than failing the fetch. - Record provenance in transferable_days_reported (migration 006) and badge derived values as estimates in the dashboard breakdown. Drop the footnote's claim that at most 150 days are transferable — real data contradicts it as a per-family figure. - Select the child's section by name when FK lists several; never guess. Verified against a live BankID scrape: scraped 240/101/139 with 129 transferable, deduced partner 240/169/71 with 71, both flagged as reported. Incidental fixes found along the way: - The fetch router never forwarded the partner's transferable figure to persist_partner_deduction, so the partner's stored snapshot would have kept the flawed split even once the parse landed. - 'deduced' snapshots were labelled "Manually entered" by a two-way ternary over a three-value union. Replaced with a compiler-checked exhaustive map. - Alembic resolved its database from alembic.ini alone, ignoring APP_SQLITE_PATH, so migrations silently targeted the developer's real database even when pointed elsewhere. env.py now resolves it, preferring -x sqlalchemy.url, then a real APP_SQLITE_PATH, then the ini value. - backend/captures/ was not ignored: the root pattern was anchored as /captures/ despite a comment saying scraper dumps must never be tracked. - CLAUDE.md quoted test counts and coverage percentages that had gone stale, which made a correct verification report look suspect. Gate thresholds kept. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DXPBfr1v7F71t6QcbHCaaT
86 lines
2.9 KiB
Python
86 lines
2.9 KiB
Python
"""Alembic environment — runs raw SQL migrations against SQLite or Postgres.
|
|
|
|
No SQLAlchemy ORM is used. Migrations are plain SQL scripts so the migration
|
|
layer stays independent of any Python model objects.
|
|
"""
|
|
|
|
from __future__ import annotations
|
|
|
|
import asyncio
|
|
import logging
|
|
from logging.config import fileConfig
|
|
from typing import Any
|
|
|
|
from alembic import context
|
|
|
|
from migrations.url_resolution import coerce_sqlite_async, resolve_database_url
|
|
|
|
# Load the alembic.ini logging config without disabling existing loggers —
|
|
# when running inside the FastAPI app the app's own loggers must not be reset.
|
|
if context.config.config_file_name is not None:
|
|
fileConfig(context.config.config_file_name, disable_existing_loggers=False)
|
|
|
|
logger = logging.getLogger("alembic.env")
|
|
|
|
|
|
def _resolve_url() -> str:
|
|
"""Resolve the database URL for this migration run.
|
|
|
|
This is the SINGLE place both the offline and online paths get their URL
|
|
from — `alembic.ini`'s `sqlalchemy.url` is deliberately never read
|
|
directly anywhere else, so Alembic can never silently target a different
|
|
database than the one the running app actually uses.
|
|
|
|
The actual resolution order/logic lives in `migrations.url_resolution`
|
|
(kept separate so it is unit-testable without an active Alembic
|
|
context); this just wires Alembic's `-x` args and ini value into it.
|
|
"""
|
|
x_args = context.get_x_argument(as_dictionary=True)
|
|
ini_url = context.config.get_main_option("sqlalchemy.url")
|
|
url = resolve_database_url(x_args, ini_url)
|
|
if not url:
|
|
raise RuntimeError(
|
|
"Could not resolve a database URL: no -x sqlalchemy.url, no "
|
|
"APP_SQLITE_PATH-derived setting, and no alembic.ini sqlalchemy.url."
|
|
)
|
|
return url
|
|
|
|
|
|
def run_migrations_offline() -> None:
|
|
"""Emit SQL to stdout (used by `alembic upgrade --sql`)."""
|
|
url = _resolve_url()
|
|
logger.info("Resolved database URL (offline mode): %s", url)
|
|
context.configure(
|
|
url=url,
|
|
target_metadata=None,
|
|
literal_binds=True,
|
|
dialect_opts={"paramstyle": "named"},
|
|
)
|
|
with context.begin_transaction():
|
|
context.run_migrations()
|
|
|
|
|
|
def do_run_migrations(connection: Any) -> None:
|
|
context.configure(connection=connection, target_metadata=None)
|
|
with context.begin_transaction():
|
|
context.run_migrations()
|
|
|
|
|
|
async def run_migrations_online() -> None:
|
|
"""Run migrations against a live DB connection."""
|
|
from sqlalchemy.ext.asyncio import create_async_engine
|
|
|
|
url = coerce_sqlite_async(_resolve_url())
|
|
logger.info("Resolved database URL (online mode): %s", url)
|
|
|
|
connectable = create_async_engine(url)
|
|
async with connectable.connect() as connection:
|
|
await connection.run_sync(do_run_migrations)
|
|
await connectable.dispose()
|
|
|
|
|
|
if context.is_offline_mode():
|
|
run_migrations_offline()
|
|
else:
|
|
asyncio.run(run_migrations_online())
|