8000 %fine-mismatch spam · Issue #6995 · urbit/urbit · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

%fine-mismatch spam #6995

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
JohnRillos opened this issue May 22, 2024 · 6 comments
Open

%fine-mismatch spam #6995

JohnRillos opened this issue May 22, 2024 · 6 comments

Comments

@JohnRillos
Copy link

For the past few weeks my terminal (on ~rivmud-fabwen) has been full of these logs

[%fine-mismatch our=[1 2] her=[~rivmud-fabwen 0 2]]

The majority of my terminal logs are just this over and over. This seems to have started when I added ~rivmud-fabwen as a delegate for ~holnes in %emissary, however uninstalling %emissary doesn't stop these logs.
@jalehman
Copy link
Collaborator

Any ideas what's going on here @pkova @midden-fabler @sigilante ?

@sigilante
Copy link
Collaborator

I wonder if someone else watching you is triggering these, possibly from an older version of %emissary (which would have the fine-mismatch of course). We've had some issues with people not upgrading and it causing an issue over the incompatibility.

@sigilante
Copy link
Collaborator

The fine-mismatch check should be a regular check (and just fail if they are on the wrong version, but on their end) but the spam is a side effect of the way fine reports these when they happen, my guess.

@JohnRillos
Copy link
Author

Looked into this more by including -v when booting. Logs look like this:

["" %unix %wake /b/behn ~2024.5.25..21.27.06..2d82]
["|" %give %behn %wake i=/ames/pump/~ribzod-taptel/184 t=[i=/ames t=~]]
["||" %pass [%ames %b] [%wait /pump/~ribzod-taptel/184] [i=/ames t=~]]
["" %unix %wake /b/behn ~2024.5.25..21.27.06..369f]
["|" %give %behn %wake i=/ames/pump/~wanted-worpel/300 t=[i=/ames t=~]]
["||" %pass [%ames %b] [%wait /pump/~wanted-worpel/300] [i=/ames t=~]]
["" %unix %hear /a/ames ~2024.5.25..21.27.06..75ef]
["" %unix %hear /a/ames ~2024.5.25..21.27.07..0c1b]
fine: miss 1 /~rivmud-fabwen/0/2/g/x/~2024.4.21..00.08.39..57e7/wiki//1/booklet-0/meta/grants/1
[%fine-mismatch our=[1 2] her=[~rivmud-fabwen 0 2]]
fine: miss 1 /~rivmud-fabwen/0/2/g/x/~2024.4.21..00.08.39..57e7/wiki//1/booklet-0/meta/releases/beta
[%fine-mismatch our=[1 2] her=[~rivmud-fabwen 0 2]]
fine: miss 1 /~rivmud-fabwen/0/2/g/x/~2024.4.21..00.08.39..57e7/wiki//1/booklet-0/meta/grants/1
fine: miss 1 /~rivmud-fabwen/0/2/g/x/~2024.4.21..00.08.39..57e7/wiki//1/booklet-0/meta/releases/beta
[%fine-mismatch our=[1 2] her=[~rivmud-fabwen 0 2]]
fine: miss 1 /~rivmud-fabwen/0/2/g/x/~2024.4.21..00.12.10..f7ab/wiki//1/booklet-0/urbit-docs/courses/app-school-full-stack/1-types
[%fine-mismatch our=[1 2] her=[~rivmud-fabwen 0 2]]
[%fine-mismatch our=[1 2] her=[~rivmud-fabwen 0 2]]
fine: miss 1 /~rivmud-fabwen/0/2/g/x/~2024.4.21..00.12.10..f7ab/wiki//1/booklet-0/urbit-docs/courses/app-school-full-stack/1-types
[%fine-mismatch our=[1 2] her=[~rivmud-fabwen 0 2]]
["" %unix %belt /d/term/1 ~2024.5.25..21.27.07..6986]
["|" %pass [%dill %g] [[%deal [~rivmud-fabwen ~rivmud-fabwen /dill] %hood %poke] /send/] [i=//term/1 t=~]]
["||" %give %gall [%unto %poke-ack] i=/dill/send/ t=[i=//term/1 t=~]]
["||" %give %gall [%unto %fact] i=/dill/peer/ t=[i=//term/1 t=~]]

Evidently the %fine-mismatches have something to do with these old %wiki paths from 4/21, which are formatted /~rivmud-fabwen/0/2/g/x/... instead of /~rivmud-fabwen/1/2/g/x/....

I'm not sure what fine: miss 1 means though. Are other ships trying to scry at those old paths, or are they scrying at new (proper) paths and the data is at an old path?

Notably the update that added remote scry functionality to %wiki was released on 4/20, so it's interesting that these timestamps are specifically for 4/21, not sure what to make of that.

@JohnRillos
Copy link
Author

Now that I think about it more, since the path is /~rivmud-fabwen/0/2/.../wiki//1/..., they actually are correctly scrying at //1/, but are using the incorrect rift 0 when ~rivmud-fabwen actually has rift 1.

Either the ship(s) making these requests don't have my correct rift or something is causing %keen to default to 0.

Still unsure why any other ship is scrying my wikis so often, it's way too often for it to be authentic page reads.

@ngzax
Copy link
Contributor
ngzax commented Oct 25, 2024

Has there ever been any more effort to figure out the cause of these... I get a lot on ~winter-paches. :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
3B69
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ngzax @jalehman @JohnRillos @sigilante
0