Repository navigation
feat(historical): start takes --window-days, text output shows the time range - #279
Conversation
…ate(window_days=) CI installs the SDK from the same-named branch archive, so the floor names the version the paired SDK change declares: 4.8.0, the next version above the 4.7.0 the SDK's develop already declares. It is mergeable once that change is on the SDK's develop, and releasable once 4.8.0 is on PyPI. Co-Authored-By: Alan Justino <alan.justino@yahoo.com.br>
-w/--window-days picks how many days back a historical hunt reaches: a closed choice of 30, 60, 90 or 180, mirroring the server's enum so a bad value is a usage error before any request. It is forwarded to historical_create as an int, and only when passed, so a script that omits it makes the same SDK call as before and the hunt reaches the platform maximum. The help does not name a day count for that maximum, because the server owns it. Tests drive the command through autospec'd SDK mocks, which also check the signature against the installed SDK. Co-Authored-By: Alan Justino <alan.justino@yahoo.com.br>
The hunt block prints a Time Range line right after Created at: "Last N days" for a hunt created with a window, "Platform maximum" for one created without (the key is null, or a server that predates it never sent it). The web UI uses the same two labels. The JSON formatter already dumps the resource's own JSON, so it carries the raw key and needed no change. The three text snapshots that render a historical hunt gain the one new line, because their recorded responses carry no window: regenerated by deleting each .click and re-running its test, with every .vcr untouched. The JSON snapshots and every other text snapshot are unchanged. Co-Authored-By: Alan Justino <alan.justino@yahoo.com.br>
|
Clean against AGENTS.md and specs/: base is |
The option keeps only its long name. It has not been released, so no invocation depends on the short form. Co-Authored-By: Alan Justino <alan.justino@yahoo.com.br>
This comment has been minimized.
This comment has been minimized.
Applies the review suggestion; the help test now checks the new wording. Co-Authored-By: Alan Justino <alan.justino@yahoo.com.br>
`historical start --window-days 30`, in text and JSON, recorded against a live e2e stack: the request carries window_days 30 and the server echoes it, which renders as `Time Range: Last 30 days`. The suite's API host was mapped to the stack for the run, so these cassettes pin the same host as every other one. Co-Authored-By: Alan Justino <alan.justino@yahoo.com.br>
|
Reviewed against AGENTS.md and specs/02, 03, 04 and 05: no issues found. The PR targets |
Findings (round 1)Adds --window-days to historical start and a Time Range line to the text output. Nothing blocking found. Part of a change across 3 PRs — merge polyswarm/polyswarm-api#332 → #279 → polyswarm/portal#2577. Reviewed at 4e19019. Fixes are suggestions; nothing was run. |
mjbradford89
left a comment
There was a problem hiding this comment.
Nothing open from this review.
TL;DR
historical starttakes--window-days {30,60,90,180}: how many days back the hunt reaches. Omit it and nothing changes; the hunt reaches the platform maximum.Time Range:line right afterCreated at::Last N days, orPlatform maximumwhen no window was requested.polyswarm_api>=4.8.0, the first version withhistorical_create(window_days=)andHistoricalHunt.window_days.Semantics
--window-days 45) is a usage error (exit 2) before any request. It is forwarded as an int and only when passed, so an invocation without it makes the same SDK call as before.Time Rangeuses the same two labels as the web UI.None(a hunt created without a window, or a response without the key) readsPlatform maximum; no day count is named for it, because the server owns that value.window_daysshows up in it as an int ornull.developtomasterPR: an unchanged invocation now prints one more line. Every text-format hunt block (historical start,view,cancel,list,delete,delete-list) getsTime Range:, including hunts that predate the field, which readPlatform maximum.Requires
historical_create(window_days=)andHistoricalHunt.window_days, and declares 4.8.0. It merges first.historical-hunt-window, see.gitlab-ci.yml), so this PR is tested against that change, and it fails loudly if the branch does not exist.developtomasterrelease: the new floor cannot be satisfied from PyPI until then. Merging here todevelopdoes not need it.Testing
pytest -s -v, against the SDK branch at 4.8.0 (editable install of the sibling checkout): 240 passed, which is the 226 ondevelopplus 14 new.tests/historical_window_test.py:window_days,--rule-id 5 --window-days 90,--window-days 45exits 2 without calling the SDK, and--help;HistoricalHuntresources:Last 30 days,Platform maximumfor both null and a missing key, placement afterCreated at:, andhunt_deletion;create,delete,list) were regenerated by deleting each.clickand re-running its test, because their recorded responses carry nowindow_days. Each differs from before only by the addedTime Range: Platform maximumline, checked by parsing the YAML. PyYAML re-folds the long create and delete scalars, so those two textual diffs show more changed lines than the one inserted. No existing.vcrfile was touched and no existing JSON snapshot changed.--stage):historical start … --window-days 30is stored and returned aswindow_days: 30and rendersTime Range: Last 30 days; without the flag the server returnsnulland the block readsPlatform maximum;historical viewandhistorical listrender both hunts the same way;--window-days 45exits 2 before any request.test_historical_hunt_create_window_jsonand_text(cli_test.py) runhistorical start eicar.yara --window-days 30against the e2e stack. The recorded request carrieswindow_days: 30, the server echoes it, and the text block readsTime Range: Last 30 days. Every cassette in this suite pins an API hostname the e2e stack no longer uses, so that name was pointed at the stack for the recording run only.