ipfs/kubo · error

failed to check pin status for requestid=%q due to error: %v

Error message

failed to check pin status for requestid=%q due to error: %v

What it means

When `ipfs pin remote add --background` (or service requiring polling) runs, kubo polls the remote pinning service with `GetStatusByID` using the returned request ID until the pin settles. If any status poll fails (network error, service 4xx/5xx, auth failure), it wraps the underlying error in this message. It is a pass-through wrapper: the real cause is the `%v` suffix.

Source

Thrown at core/commands/pin/remotepin.go:240

			// TODO: confirm this works as expected
			p, err := peer.AddrInfoFromP2pAddr(d)
			if err != nil {
				return err
			}
			if err := api.Swarm().Connect(ctx, *p); err != nil {
				log.Infof("error connecting to remote pin delegate %v : %w", d, err)
			}
		}

		// Block unless --background=true is passed
		if !req.Options[pinBackgroundOptionName].(bool) {
			const pinWaitTime = 500 * time.Millisecond
			var timer *time.Timer
			requestID := ps.GetRequestId()
			for {
				ps, err = c.GetStatusByID(ctx, requestID)
				if err != nil {
					return fmt.Errorf("failed to check pin status for requestid=%q due to error: %v", requestID, err)
				}
				if ps.GetRequestId() != requestID {
					return fmt.Errorf("failed to check pin status for requestid=%q, remote service sent unexpected requestid=%q", requestID, ps.GetRequestId())
				}
				s := ps.GetStatus()
				if s == pinclient.StatusPinned {
					break
				}
				if s == pinclient.StatusFailed {
					return fmt.Errorf("remote service failed to pin requestid=%q", requestID)
				}
				if timer == nil {
					timer = time.NewTimer(pinWaitTime)
				} else {
					timer.Reset(pinWaitTime)
				}
				select {
				case <-timer.C:

View on GitHub (pinned to 329838acdf)

Solutions

  1. Read the wrapped `%v` cause and fix it (auth token, connectivity, rate limit).
  2. Retry the operation: check status manually with `ipfs pin remote ls --service=<svc> --status=pinned|failed` to see whether the pin eventually succeeded.
  3. Re-issue the `pin remote add` if the remote request was dropped; request IDs are not recoverable.
  4. Verify service config with `ipfs pin remote services ls` and re-add with correct endpoint/key.
  5. Add retry/backoff around background pin operations in automation.

Example fix

// before
client.Request("pin/remote/add").Option("service", svc).Option("bg", true).Arguments(cid).Send(ctx)
// after — verify service auth up front and surface cause
if err := verifyServiceAuth(ctx, svc); err != nil { return fmt.Errorf("remote pin service %s unavailable: %w", svc, err) }
client.Request("pin/remote/add").Option("service", svc).Option("bg", true).Arguments(cid).Send(ctx)
Defensive patterns

Strategy: retry

Validate before calling

// verify service credentials and reachability before a background add
if err := client.Request("pin/remote/services/ls").Send(ctx); err != nil {
    return fmt.Errorf("remote pinning service unreachable: %w", err)
}

Try / catch

for attempt := 0; attempt < 3; attempt++ {
    if err := remotePinAdd(ctx, svc, cid); err != nil {
        if strings.Contains(err.Error(), "failed to check pin status") {
            time.Sleep(backoff(attempt)); continue
        }
        return err
    }
    break
}
// afterwards confirm with: ipfs pin remote ls --service=svc --status=pinned

Prevention

When it happens

Trigger: Remote pinning service temporarily unreachable or returning HTTP errors while kubo polls; invalid/expired service credentials causing per-request rejections; request ID lost on the service side (e.g. pin garbage-collected on the remote).

Common situations: Using pinning services behind flaky networks or rate limits; wrong/rotated API tokens in `ipfs pin remote service add`; service restarts losing queued pin requests mid-poll.

Related errors


AI-assisted analysis of ipfs/kubo@329838acdf (2026-09-03). Data as JSON: /api/errors/b1bfc0e795edb822. Report an issue: GitHub.