in the lists; this is easier to read than a strikethrough.
I experimented with text-decoration-style and text-decoration-style but that
didn't make it better.
Our big brother doesn't bother to reveal the resolvedness of issues in lists
_at all_, btw. Surprising!
Multiple problems w/ <a name
* in itself deprecated
* my approach of self-closing <a is illegal too
replaced w/ spans where necessary.
Further notes:
'topp' was never used; '#top' is taken too, so I went with first-frame (stil unused, 'maybe later')
The fixes in this and preceding commits were inspired by running "Nu Html Checker"
docker run -it --rm -p 8888:8888 ghcr.io/validator/validator:latest
files were simply saved in Firefox and then uploaded; make sure to ignore the warning which is caused by Firefox:
> A document must not include both a meta element with an http-equiv attribute whose value is content-type, and a meta element with a charset attribute.
I limited checking to the issue-list and various event-detail pages.
* As per the spec 'takes precendence'
* Also fixes the reported bug on Laravel, which apparently doesn't send event_id
as part of the event payload.
* Fixes the envelope tests (they were doing nothing when I moved the
data samples around recently)
* Adds a 'no event_id in data, but yes in envelope' test to that test.
* Adds handling to send_json such that we can send envelopes when the event_id
is missing from the event data.
This reverts course on 4201fbd778, and restores event.schema.json from that
commit. In that commit we said: 'this is not used'. Not true: it's used in a
test, though this test used the validity check to silently skip.
In this commit:
1. Do _not_ just silently skip invalid samples. Since we have a way of properly
validating, let's use that so that we know how useful the samples that we have
actually are.
2. Deal with "_meta", a field that we sometimes see in the "private samples" (data
that ultimately comes from running a somewhat recent python-sdk against my
actual codebase). The need for this was exposed by [1]
3. Add a test for the up-to-date-ness of event.json.schema
4. remove special-cased attribute-checks in `is_valid`; `send_json` was, at the
time, an opportunistic way to just get my hands on some sample data. the
approach at validation reflected that: I just did some tests on the existence
of certain attributes to determine which json files were even events. But in
the end I did a full validation using an API schema, which kinda made the
whole business useless. This commit cleans up the individual checks.
recently introduced (e59fd3a225) caching made it so that repeated calls to
create_release_if_needed no longer work if releases have been created in the
meantime.
In actual usage create_release_if_needed is always called on a single project
so I _think_ just calling `fresh` in the tests is good way to get to green
tests again.
Now that we have eviction, events may disappear. Deal with it:
* event-specific 404 that still allows for navigation
* first/last buttons
* navigation to prev/next when prev/next is not just 1 step away
* don't use HttpRedirect for "lookup based" views
in principle, the thing you were looking for might go missing in-between
drawback: these URLs are not "stable"
* issue.event_count to digested_event_count
* event.ingest_order to event.digest_order
* issue.ingest_order to digest_order
This is generally more correct/explicit, and is also in preparation
of doing work on-digest (which may or may not happen)
The direct cause for this was the following observation: there was no mechanism
in place to safeguard counted events across evictions, i.e. the following order
of events was not accounted for:
* ingest/digest a bunch of events (PCs correctly updated)
* eviction (PC still correct)
* server/snappea restart (PC reloaded, but based on new events. not correct).
I though about various approaches to fix this (e.g. snapshotting) but in the end
such approaches added even more complexity to the PC mechanism. I decided to first
check how non-performant the SQL route would be, and this PoC seems to say: just
go SQL.
There's also a small semantic change (probably in the direction of what you'd
expect), namely: the periods are no longer 'calendar' periods.
Klaas van Schelven