the IPFS companion is disabled even with Kubo is running

[siiky]

Describe the bug

Starting with one of the latest 2 or 3 releases, the IPFS companion seems to be disabled from time to time, even if Kubo is running.

When that happens, if I open a site such as ipfs.tech, it'll load through HTTP instead of redirecting to http://ipfs.tech.ipns.localhost:8081. If I hit the icon on the browser to open the companion menu, it'll then connect to Kubo and everything works as usual.

To Reproduce

I haven't found a pattern, it just happens sometimes... I can be sure that Kubo is running, however -- notice the Active line, it's been up for 2 weeks and 3 days:

$ systemctl --user status ipfs
● ipfs.service - InterPlanetary File System (IPFS) daemon
     Loaded: loaded (/home/$USER/.config/systemd/user/ipfs.service; enabled; preset: enabled)
     Active: active (running) since Sun 2023-09-10 20:13:23 WEST; 2 weeks 3 days ago
       Docs: https://docs.ipfs.io/
   Main PID: 1277 (ipfs)
      Tasks: 139 (limit: 38327)
     Memory: 652.9M (swap max: 0B)
        CPU: 1h 59min 29.095s
     CGroup: /user.slice/user-1001.slice/user@1001.service/app.slice/ipfs.service
             └─1277 /home/$USER/.local/bin/ipfs daemon --migrate

Sep 10 20:54:19 $HOSTNAME ipfs[1277]: ⚠️ Your system might be struggling to keep up with DHT reprovides!
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: This means your content could partially or completely inaccessible on the network.
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: We observed that you recently provided 129 keys at an average rate of 16.295281359s per key.
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: 🕑 An attempt to estimate your blockstore size timed out after 5 minutes,
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: implying your blockstore might be exceedingly large. Assuming a considerable
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: size of 10TiB, it would take 379707h34m35.70358272s to provide the complete set.
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: ⏰ The total provide time needs to stay under your reprovide interval (22h0m0s) to prevent falling behind!
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: 💡 Consider enabling the Accelerated DHT to enhance your system performance. See:
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: https://github.com/ipfs/kubo/blob/master/docs/config.md#routingaccelerateddhtclient
Sep 10 22:15:09 $HOSTNAME ipfs[1277]: 2023/09/10 22:15:09 http: superfluous response.WriteHeader call from github.com/prometheus/client_golang/prometheus/promhttp.(*responseWriterDelegator).WriteHeader (delegator.go:65)

(Those logs are from more than 2 weeks ago, they don't seem related? Could be wrong... I just didn't get around to taking care of that yet.)

Expected behavior

If Kubo is running, the companion should automatically connect and stay connected.

Desktop (please complete the following information):

• OS: Debian testing
• Browser: Firefox 119.0b2
• IPFS companion: 3.1.0

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within seven business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[whizzzkid]

Thanks for submitting this issue @siiky, did you notice a pattern between sleeps? in the new companion MV3 implementation, the companion can actually go to sleep as companion does not interact with an active request. However the browser should already have the rule and this should automatically redirect.

I'll try reproducing this (not been successful so far) but this most likely looks like a bug with the MV3 implementation in chromium browser as per preliminary investigation.

Please keep me posted if you find a reliable way to reproduce or the problem worsens.

[siiky]

Hey @whizzzkid, thanks for taking a look. I noticed that the companion is offline whenever I open the browser, i.e., if I close and open the browser again, it'll be offline. Note that I'm using Firefox, not Chromium/Chrome (maybe that's not what you meant, just wanted to clarify). Also added to the report the companion version I'm currently using: 3.1.0.

However the browser should already have the rule and this should automatically redirect.

That's kind of working. With the companion offline, if I open e.g. ipns://ipfs.tech/, I'll be redirected to https://ipfs-tech.ipns.dweb.link/ instead of to http://ipfs.tech.ipns.localhost:8081/

[lloy0076]

I'm experiencing the same thing in ipfs/ipfs-webui@a43dd23 on FireFox in Windows (118.0.1 (64-bit)) and the extension claims it's 3.1.0.

[lloy0076]

Indeed, unless I manually click on it and force it to activate, it doesn't redirect me to my Kubo node (which almost defeats the purpose of why I run it).

[lloy0076]

I'll try reproducing this (not been successful so far) but this most likely looks like a bug with the MV3 implementation in chromium browser as per preliminary investigation.

It's happening in FireFox on Windows too - I don't know if it's just Chromium browsers.