"failed to initialize execute state: could not find bucket" most of the time

New user. Signed up to use free account, sent a few MB of data.

The cloud v2 ui is really buggy: feels like half the time it just says "failed to initialize execute state: could not find bucket ". I click around a bit, and things mysteriously start working for a bit, before reverting.

Am I doing something wrong? Is this typical on the free account, like caused by a throttle or something? The first impression it gives is not great

I tried from Safari and Google Chrome, from multiple computers (all Macs, but hey). Same everywhere. Also I searched the documentation and forums - nothing else mentions the same error message

Hi @mozz100,

If possible, could you record your screen?

Right now I’m now sure what problem you’re hitting, but could you try to logout and back in, please?

We’ll keep you get passed this :+1:

Thanks for the response. Hope you can get to the bottom of this.

Here’s a (silent) screencast of the problem: https://v.usetapes.com/iq0Cs1tt3z

And here’s the (crazy!) behaviour I get when logging out/in. I resorted to a private browser window and logged in. Mystery bucket behaviour still happening afterwards: https://v.usetapes.com/akFdTnVuwo


We rolled out some updates. Can you let us know if this is still happening, please?


I haven’t seen it happen again for a few days now. Hope that was it.

1 Like

I just signed up for InfluxDB Cloud 2 on Azure, free account, and I am seeing this error most of the times while trying to query any data. I didn’t see any data being reverted though.

Same here, opened a trial account - get

failed to initialize execute state: failed to look up bucket

for existing bucket.

Could be related to https://github.com/influxdata/influxdb/issues/19399
Though I was not able to reproduce this recently.

Hi, I found out that in Influxdb 2.0.4, just released Feb 4 as GA, that I cannot restore (a backup created with "influx backup) to an existing bucket. Tried all combinations. So I added a delete bucket to the script and then restored to the bucket I wanted, using this: “influx restore -c default -o commscope --bucket telemetry --new-bucket telemetry --new-org commscope --input /tmp/backupTelemetry /tmp/backupTelemetry” and that “works” however, when I log back into the container (this is a v2.0.4 docker inside a kubernetes pod) and try to query from the bucket, using: influx query ‘from(bucket:“telemetry”) |> range(start: -15d)’ it returns this: Error: Failed to initialize execute state: could not find bucket “telemetry”.
See ‘influx query -h’ for help But the bucket is there:

but the bucket is there; # influx bucket list -c default
ID Name Retention Organization ID
db75828123589748 _monitoring 168h0m0s 9880bacb06b676ee
3dd3394c6332ca7a _tasks 72h0m0s 9880bacb06b676ee
96301b50be7cb690 alarms 720h0m0s 9880bacb06b676ee
5d5bb0fae5ea9e4c telemetry 720h0m0s 9880bacb06b676ee

I’m surprised about not being able to restore to an existing bucket, as it creates a bunch of work if deleting it in order to restore, as then I have to redo user auths that were associated with the bucket since the bucket will change ID. However, that aside, I’m currently stuck. This is a show stopper for us in regard to using 2.0.4. My restore script also restored the alarms bucket, after dropping it in order to restore and it is in the same situation:

influx query ‘from(bucket:“alarms”) |> range(start: -15d)’
Error: Failed to initialize execute state: could not find bucket “alarms”.
See ‘influx query -h’ for help

BTW, in regard to the “Error: Failed to initialize execute state: could not find bucket “telemetry”.” After dropping the bucket in order to restore it, one needs to remove the auth for users accessing such bucket(s) and rebuild the auth granting privileges on the new buckets (ID changes, not surprisingly with bucket remove/re-create). Using the admin token also works, I didn’t add any “-c default” to the end of the query, which does the trick. I’ll have to add the auth removal, config using that auth removal, create new auth for the changed bucket IDs and create a new config based on that new auth. A lot more work than it would be to simply be able to restore to an existing bucket (btw, I tried with -f and --force (thinking maybe they just weren’t documented, but neither worked).