Commit 38961b0
authored
feat: error if modified date for existing advisories is ahead of the proposed modified date (#70)
Now that we're starting to generate advisories autonomously, it's
possible that local caches could get outdated meaning that regenerating
the advisories after doing a change could mistakenly revert advisory
updates or skip advisories that have since been published.
This introduces a check to help guard against that whereby we error if
the `modified` timestamp for the version of the advisory we've just
generated is behind the `modified` timestamp for the version of the
advisory that exists on disk which should be an indicator that the local
advisory cache is out of date.
I think this should be robust enough but I wouldn't be surprised if
there's an edge case or two that we discover later - I'm not really
worried about that though due to the utility of this check and worst
case you can just locally hardcode the function to return `False` as a
workaround.
Also just want to acknowledge we're technically opening the file twice
in a row but I found attempting to do this within the context of the
single file handler was a lot uglier since we have to account for the
advisory not existing ideally without suppressing if the file has
invalid JSON - in the scheme of things, the performance hit of doing a
double open will likely never be measurable 🤷1 parent 09830a1 commit 38961b0
1 file changed
Lines changed: 18 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
420 | 420 | | |
421 | 421 | | |
422 | 422 | | |
| 423 | + | |
| 424 | + | |
| 425 | + | |
| 426 | + | |
| 427 | + | |
| 428 | + | |
| 429 | + | |
| 430 | + | |
| 431 | + | |
| 432 | + | |
| 433 | + | |
| 434 | + | |
423 | 435 | | |
424 | 436 | | |
425 | 437 | | |
| |||
442 | 454 | | |
443 | 455 | | |
444 | 456 | | |
| 457 | + | |
| 458 | + | |
| 459 | + | |
| 460 | + | |
| 461 | + | |
| 462 | + | |
445 | 463 | | |
446 | 464 | | |
447 | 465 | | |
| |||
0 commit comments