sbws consensus timestamp updates incorrectly use the current time

There is a race condition in the sbws relay consensus timestamp update code.

sbws uses the current timestamp (now) when the same consensus is retrieved twice. Instead, it should just keep the same (valid-after) timestamp.

changed milestone to %sbws: 1.1.x-final

Trac:
Parent Ticket: #30733 (moved)

added actualpoints::0.2 component::core tor/sbws milestone::sbws: 1.1.x-final parent::30733 points::0.2 priority::medium resolution::fixed reviewer::juga sbws-ci-fail-sometimes severity::normal status::closed type::defect version::sbws 1.1.0 labels

See my pull request: https://github.com/torproject/sbws/pull/360

It checks the valid-after time and the timestamp in the same way, so this bug shouldn't happen any more. If it does, we should fix the test code.

Trac:
Reviewer: N/A to juga
Status: assigned to needs_review

lgtm, just added a comment regarding the commit.

Trac:
Status: needs_review to merge_ready

I realized about other bug, fixed in https://github.com/juga0/sbws/commits/bug30909_11. I'm not sure which the workflow should be here, so just changing this ticket to needs review, but not doing PR nor assigning reviewer.

Trac:
Status: merge_ready to needs_review

Trac:
Status: needs_review to needs_revision

I am not actively working on this ticket

Trac:
Owner: teor to N/A
Status: needs_revision to assigned

Trac:
Status: assigned to needs_revision

Replying to juga:

I realized about other bug, fixed in https://github.com/juga0/sbws/commits/bug30909_11. I'm not sure which the workflow should be here, so just changing this ticket to needs review, but not doing PR nor assigning reviewer.

Since this ticket is blocking #30733 (moved) and the potential bug it's not related to teor's patch, i've created #33060 (moved) for it and changing this one to merge ready.

Trac:
Status: needs_revision to merge_ready

Merged

Trac:
Status: merge_ready to closed
Resolution: N/A to fixed

closed

changed time estimate to 1h 36m

added 1h 36m of time spent

mentioned in issue #33060 (moved)

mentioned in issue #30733 (moved)

moved to tpo/network-health/sbws#30909 (closed)

mentioned in issue tpo/network-health/sbws#33060 (closed)