panic divide by zero related to second precision

Writes into original / Source instance with precision=s are successful.

Customer takes backups from that original instance and restores into another instance
Customer then attempts Writes on the second instance, that runs into this issue.

It appears that this exact scenario is discussed on the InfluxDB blogs:

https://community.influxdata.com/t/influxdb-2-1-1-internal-server-error-timestamp-related/23994/14

https://stackoverflow.com/questions/78544365/facing-error-panic-has-occurred-api-v2-writeorg-test-bucket-test-precision-s

The workaround described is to copy the restored bucket into a new bucket on the target instance and then attempt writes. Please attempt this and see if that fixes the write issue. They could also try this approach to restore data:

https://docs.influxdata.com/influxdb/v2/write-data/migrate-data/migrate-oss/

by taking a line protocol dump directly from a source instance and writing all the datapoints without restoring any other metadata from the source instance, to rule out issues / bugs in the backup/restore functionality of InfluxDB.

Panic stack trace from the community issue above:
pretty_panic.txt

We have not yet successfully reproduced this issue, either with backup and restore, or with direct writes (as outlined in some of the community forum posts).

The issue is that a shard group is somehow ending up with no shards, causing a divide by zero error when the length of the shards is used as a divisor.