Skip to content
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.

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

One nickname which is null blocks access to all other identities in WebOfTrust #26

Open
Spider-Admin opened this issue Dec 21, 2022 · 2 comments
Labels
not a bug issue is not a bug but intended behaviour

Comments

@Spider-Admin
Copy link

Hi,

as reported in FMS, I had to recover my identities from WebOfTrust. One identity was recovered, while another one was stuck in recovery state. Both identities have Sone.

I was unable to use Sone with my recovered identity because there was this exception in the logs:

<timestamp> (net.pterodactylus.sone.freenet.wot.IdentityManagerImpl, Sone Identity Manager, ERROR): Uncaught exception in IdentityManager thread!
java.lang.IllegalStateException: get("Nickname$index") must not be null
at net.pterodactylus.sone.freenet.wot.PluginWebOfTrustConnectorKt.parseOwnIdentity(PluginWebOfTrustConnector.kt:103)
at net.pterodactylus.sone.freenet.wot.PluginWebOfTrustConnectorKt.access$parseOwnIdentity(PluginWebOfTrustConnector.kt:1)
at net.pterodactylus.sone.freenet.wot.PluginWebOfTrustConnector$loadAllOwnIdentities$1.invoke(PluginWebOfTrustConnector.kt:43)
at net.pterodactylus.sone.freenet.wot.PluginWebOfTrustConnector$loadAllOwnIdentities$1.invoke(PluginWebOfTrustConnector.kt:35)
at net.pterodactylus.sone.freenet.wot.PluginWebOfTrustConnectorKt$parseIdentities$2.invoke(PluginWebOfTrustConnector.kt:99)
at net.pterodactylus.sone.freenet.wot.PluginWebOfTrustConnectorKt$parseIdentities$2.invoke(PluginWebOfTrustConnector.kt)
at kotlin.sequences.TransformingSequence$iterator$1.next(Sequences.kt:172)
at kotlin.sequences.SequencesKt___SequencesKt.toCollection(_Sequences.kt:716)
at kotlin.sequences.SequencesKt___SequencesKt.toSet(_Sequences.kt:757)
at net.pterodactylus.sone.freenet.wot.PluginWebOfTrustConnectorKt.parseIdentities(PluginWebOfTrustConnector.kt:100)
at net.pterodactylus.sone.freenet.wot.PluginWebOfTrustConnectorKt.access$parseIdentities(PluginWebOfTrustConnector.kt:1)
at net.pterodactylus.sone.freenet.wot.PluginWebOfTrustConnector.loadAllOwnIdentities(PluginWebOfTrustConnector.kt:43)
at net.pterodactylus.sone.freenet.wot.IdentityLoader$loadAllIdentities$2.invoke(IdentityLoader.kt:41)
at net.pterodactylus.sone.freenet.wot.IdentityLoader$loadAllIdentities$2.invoke(IdentityLoader.kt:29)
at net.pterodactylus.sone.freenet.wot.IdentityLoader.time(IdentityLoader.kt:82)
at net.pterodactylus.sone.freenet.wot.IdentityLoader.loadAllIdentities(IdentityLoader.kt:40)
at net.pterodactylus.sone.freenet.wot.IdentityManagerImpl.serviceRun(IdentityManagerImpl.kt:66)
at net.pterodactylus.util.service.AbstractService.run(AbstractService.java:441)
at java.base/java.lang.Thread.run(Thread.java:832)
at net.pterodactylus.util.thread.DumpingThread.run(DumpingThread.java:104)

My suggestion: Just skip identities, which are null, when iterating existing identities.

@Bombe
Copy link
Owner

Bombe commented Dec 22, 2022

Hmm, this happens when parsing one of your local identities and it sounds like your recovery was somehow botched. While of course this code can be made more forgiving, I am not sure about the ramifications of doing so. Sure, this exception is mighty inconvenient when you want to run Sone on a broken WoT installation but simply ignoring a broken identity would make people wonder why their identities don’t show up in Sone, and nobody checks log files, ever… 🙂

@Bombe
Copy link
Owner

Bombe commented Dec 22, 2022

For the record, remote identities that are broken like this are already ignored. I’m not convinced doing the same for local identities is a good idea because while you can’t be made responsible for other people’s broken WoTs you sure are responsible for the state of your own WoT. 🙂

@Bombe Bombe added the not a bug issue is not a bug but intended behaviour label Dec 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not a bug issue is not a bug but intended behaviour
Projects
None yet
Development

No branches or pull requests

2 participants