refactor: acled - #218
Open
nikbpetrov wants to merge 9 commits into
Open
refactor: acled#218nikbpetrov wants to merge 9 commits into
nikbpetrov wants to merge 9 commits into
Conversation
Collaborator
Author
|
Parity test only on update job (not running fetch!): old vs new (main branch code vs pr code) is perfectly identical; both disagree partially (712 file diffs out of 3374) with prod but only because prod's computation of |
…b entrypoints `AGENTS.md` (added on main after this branch forked) says new ForecastBench Python files should not add it, and neither entrypoint needs postponed annotations.
…uirements The update job needed it only because `orchestration/_io` imported `helpers.keys` at module level. Main now imports `keys` lazily inside the one function that uses it, and the acled update job never reads a secret. This matches `func_fred_update`, which also omits it.
de28285 returned an empty frame so the fetch job's `if dff.empty` guard could log and exit 0. That turned a broken fetch into a success, and the nightly worker then ran the update job on the previous week's fetch file, recomputing freeze values against stale data. Raise instead, as legacy did (via `pd.concat([])`) and as `DbnomicsSource.fetch()` does, and drop the job guard. Explicit handling of empty fetch results is what forecastingresearch#319 asks for.
`_prepare_resolution_data` was annotated as returning a `list` of countries but returned the ndarray from `.unique()`, so convert it to a list and type both sequences as `list[str]`.
Collaborator
Author
nikbpetrov
marked this pull request as ready for review
October 3, 2026 12:24
…lers `id_hash` and `upload_hash_mapping` were called only by the legacy update job this branch deletes; the new update job hashes on its own `AcledSource` instance. They were kept for fidelity with main during the refactor. `base_eval` still uses `populate_hash_mapping` and `id_unhash`, which stay.
Collaborator
Author
|
Tests pass again (same pattern as before). |
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.
requirements.txtchange forbase_eval- unavaoidable w/o a ton of additional hassle; comments explain why/what; will repeat for wikipediaAcledFetchFrameas well as the explicit dtype columns is smelly but can't be avoided unless we do a full refactor of acled_require_api_key()on the base class)_io._read_acled_dfr()is refactored to reuseacled._prepare_resolution_data()(DRY); this means that resolve and base_eval/naive and dummy forecaster jobs both bring in the heavy acled depsrequestsandnumpymodules but both resolve/base eval bring those in implicitly (google-cloud-storagebrings inrequests,pandasbrings innumpy) - this is behaviour not tied to this PR@backoff.on_exception on _get_access_tokenbehaviour change: instead of manual handling, we letbackoffhandle retries/erroring, matching other sources' behaviour