ldeffenb

You might want to turn on debug level logging and do the delete again. IIRC, the unpinning action has additional details that log showing more about what the issue might...

Actually, there are 3 different use cases for the /stewardship API, both GET and PUT. 1) Current operation which traverses an entire manifest if the reference "smells" like one, and...

I actually have 4 chunks (out of 55 million) in one of my source nodes that steadfastly refuse to get back into the swarm via a PUT /stewardship API invocation....

Sorry for the delay, but I've located the 4 /bytes uploads and the associated chunks that refuse to pushsync into the swarm right now. Not that it matters, but the...

So, would this stamp help? It's currently just short of 24% utilized with uploaded content already in the swarm: "batchID": "0e8366a6fdac185b6f0327dc89af99e67d9d3b3f2af22432542dc5971065c1df", "utilization": 3926, "usable": true, "label": "20210916-OSM-Map", "depth": 30, "amount":...

I do agree that this can be considered a non-blocker, and I also suspect that the issue is not new. It's just that I've been working the much larger/deeper mainnet...

> It is in undocumented `/chainstate`. I am closing this bug and opening a bug in `bee-docs`. But apparently this issue is still open? @vporton If the bee-docs issue has...

> It should be in main API rather than in Debug API. Apparently that's a distinction that is going away in some future update anyway.

This issue gets really bad when something causes the node's depth to decrease substantially in a short time, for instance if IPv4 connectivity is lost but IPv6 connectivity remains.

> > IPv4 connectivity is lost but IPv6 connectivity remains. > > huh? This happened to a VPS that I'm running. The provider thought my ipfs node was attacking the...