Articles are lost and keep reappearing
For the last couple of days I have seen the case where I saw the last from planetable.eth "Updating IPFS Configurations for ENS Resolution After Cloudflare Changes" appearing as a new article.
For some reason the article gets lost and then it downloads again.
This has happened 4 or 5 times in the last couple of days.
Thanks for reporting. Recently, I noticed an outage on Cloudflare's side, which can cause issues when resolving ENS domains. As mentioned in the article:
https://planetable.eth.limo/kubo-config-ens/
I'm working on a fix. If you are interested in helping test the latest Insider build, you can download it here:
https://github.com/Planetable/Planet/releases/tag/insider-20250102-3
I absolutely want to help. I always run the latest Insider build so I was already on that build.
Happened twice today with the same article.
Just happened again. Same article.
Just happened again. Same article.
I would very much like to replicate this issue locally. It would be incredibly helpful if you could send me a zip file of the following folder:
~/Library/Containers/xyz.planetable.Planet/Data/Documents/Planet/Following
This folder contains some JSON metadata files of your followed content sources.
Thank you very much!
Also, if you open Activity Monitor and search for ipfs, how many processes do you see?
Normally, there should be only one process, like this:
If you see more than one, it might be due to earlier insider builds with the --enable-gc option enabled. We discovered that with --enable-gc, the ipfs process did not terminate cleanly alongside the main Planet process. To address this, we removed the option in later builds and added a manual garbage collection button, as mentioned here:
https://github.com/Planetable/Planet/issues/390
If you see multiple processes, quit the Planet app, terminate all ipfs processes in Activity Monitor, and then restart the app.
Happened again today. Same article.
By the way, if you want to make a special build that enables tons of logging that could help you fix this, I'm willing to run it.
I appreciate your help.
So far, I have not been able to reproduce the issue locally, but I am actively working on it. I suspect it has something to do with the logic we use when checking for updates. Specifically, it removes an article if it no longer exists in the source. However, in this case, it seems to be executed in an unintended way.
I’ll continue working on it.
This is still happening. Same article.
The latest Insider build 20250115-3 is testing a fix for this issue.
Seems to be fixed after that commit. Closing for now.
Since I updated to the new build yesterday, the bug reappeared and I have experienced it twice so far.
Since I updated to the new build yesterday, the bug reappeared and I have experienced it twice so far.
Yes, I re-enabled the deletion behavior because of another issue.
Can you please try to unfollow planetable.eth and follow again?
I just did. Let's see if it helps.
Got it again, so still happening.
While I am unable to reproduce the issue locally, here is my best guess:
When this happens, your local IPNS resolving gets an outdated CID record from the P2P networks. If so, you can Copy CID and paste it here.
- CID when the article is present.
- CID when the article is deleted unexpectedly.
Many thanks.
Right now, the latest CID for planetable.eth is bafybeig3dpkkhp67s3xqbanzthfjulqjupyxysra2kxabcpxvgdpq2hrka. If you get anything other than that, that is most likely the root cause of the issue.
In c3a0c21 I added a measure to prevent unexpected deletion: if the updated field in the latest resolved CID is older than the local one, then it will not trigger any update.