Closed ElijahLynn closed 1 year ago
So it appears that when it panicks, the user login title not found
.
23:45:30 [INFO] set_failure: https://va-gov-cms.ddev.site/user/login: title not found: elijah.lynn@va.gov
So it appears that when it panicks, the user login
title not found
.23:45:30 [INFO] set_failure: https://va-gov-cms.ddev.site/user/login: title not found: elijah.lynn@va.gov
I'll try with less users load to see if maybe it is a legitimate application issue. If it is we may be able to better handle that error though.
It appears it had to do with the edit transaction and the titles maybe not matching with final_url
and self.raw.url
. Not 100% yet though.
Gonna close this for now and rubber duck it again when I get back to needing to load test /edit/%
, as right now I just need authd GETs.
In GooseRequestMetricAggregate fail_count is an unsigned integer. The assumption is that fail_count
will only be decremented if it was previously incremented.
Your error at metrics.rs line 2801 suggests that a fail_count
is being decremented that wasn't ever incremented.
Updates to metrics would happen due to calls to GooseUser::set_failure. The set_failure function should be called with the already-recorded request, do you have logic that's re-using a GooseRequestMetric?
Thanks, I can't recreate anymore as I wiped that code. But if/when I see this again I'll get some more info based on your suggestions.
update: Oh, note to self, this was when I was trying to adapt the "edit" Umami code to our example. This was in the Goose repo, not using goose-eggs in our application repo.
I've tried to duplicate but have been unable. For this to panic, you're running without --release
, something I rarely do. I've tried causing a variety of errors while running --example umami
without using --release
but I've been unable to trigger a panic.
@slashrsm @LionsAd While I can't duplicate this, a "solution" would be to convert fail_count
to a signed integer. That said: nearest I can tell this can only happen when we're incorrectly modifying metrics (specifically, by passing the wrong GooseRequestMetric
to set_failure()
. Is it better to panic when there's negative metrics? Or to display them?
I remain unable to duplicate, and per my notes above this seems to be a mis-use of internal structures. Closing. Feel free to re-open if you can provide more info on duplicating or disagree with my analysis above.
Thanks @jeremyandrews, I am not on that project anymore so won't be able to tinker with that right now. I think it is good to close for now.
Seeing this panic intermittently, with command
cargo run --example va -- --host https://va-gov-cms.ddev.site --report-file report-file.html --running-metrics 5
. It doesn't happen consistently but happens quite a bit right now. I did modify the Umami example a decent amount and copied to./examples/va/
.Just ran it with
RUST_BACKTRACE=1
and got more but I'm not seeing it to be related to Goose just yet:When it is successful it outputs: