Bug: async archive mode panics when storageConfig is omitted from PluginConfig

Summary

When using the Dalibo pgBackRest CNPG-I plugin in asynchronous archive mode, the plugin panics during lifecycle reconciliation if spec.storageConfig is omitted from the PluginConfig.

According to the documentation, storageConfig appears to be optional and is only used to specify which StorageClass should be used when a dedicated PVC is desired for spooled WAL files.

In practice, with archiveAsync: true and no storageConfig, the plugin crashes with a nil pointer dereference in injectWALVolume.

Expected behavior

One of the following should happen:

1. storageConfig is truly optional in async mode, and the plugin should not panic when it is omitted.
2. If storageConfig is actually mandatory when async mode is enabled, this should be enforced explicitly by validation or by a clear error message, not by a runtime panic.

Actual behavior

The PostgreSQL cluster enters an error state:

Cluster cannot proceed to reconciliation due to an error while interacting with plugins

The plugin logs show a panic:

panic caught: runtime error: invalid memory address or nil pointer dereference

github.com/dalibo/cnpg-i-pgbackrest/internal/operator.LifecycleImplementation.injectWALVolume
	/app/internal/operator/lifecycle.go:455
github.com/dalibo/cnpg-i-pgbackrest/internal/operator.LifecycleImplementation.reconcilePod
	/app/internal/operator/lifecycle.go:565
github.com/dalibo/cnpg-i-pgbackrest/internal/operator.LifecycleImplementation.LifecycleHook
	/app/internal/operator/lifecycle.go:100

Documentation reference

Documentation page:

https://plugin-pgbackrest.readthedocs.io/en/latest/docs/configuration

Relevant wording:

Specify the StorageClass to use when creating a PersistentVolumeClaim (PVC) to store transient data for spooled WAL files when running in asynchronous mode. Using a dedicated PVC ensures that we don't lose information about processed WAL when operating in asynchronous mode in case the sidecar container crashes.

This wording suggests storageConfig is an optional customization, not a required field to avoid a plugin crash.

Observed schema behavior

In the PluginConfig CRD schema, storageConfig is optional at spec level.

Only storageClass is required if storageConfig is present.

Example:

spec:
  storageConfig:
    storageClass: sample-storageclass

This also suggests the whole storageConfig block is optional.

Minimal reproduction

PluginConfig

apiVersion: pgbackrest.dalibo.com/v1
kind: PluginConfig
metadata:
  name: sample-pluginconfig
  namespace: default
spec:
  resourcesRequirement:
    requests:
      cpu: 100m
      memory: 64Mi
    limits:
      cpu: 500m
      memory: 256Mi
  exporterConfig:
    enabled: true
    collectInterval: 60

Stanza

apiVersion: pgbackrest.dalibo.com/v1
kind: Stanza
metadata:
  name: sample-stanza
  namespace: default
spec:
  stanzaConfiguration:
    name: sample
    archive:
      async: true
      getQueueMax: 4GiB
    s3Repositories:
      - bucket: demo-bucket
        endpoint: https://s3.example.local
        region: fr-par
        repoPath: /default/sample
        uriStyle: path
        verifyTLS: false
        secretRef:
          accessKeyId:
            name: sample-secret
            key: s3_key
          secretAccessKey:
            name: sample-secret
            key: s3_secret_key

Cluster

The cluster references the plugin and the PluginConfig/Stanza in the normal way.

Additional notes

• We initially worked around the issue by generating storageConfig with a default storageClass, but that forces creation of a PVC even when we do not want one.
• The current question is whether async mode should be supported without a dedicated spool PVC, as suggested by the documentation/conversation, or whether the plugin implementation should require and validate it explicitly.

Questions

1. Is async mode without storageConfig supposed to be supported?
2. If yes, could you fix the nil dereference in injectWALVolume?
3. If no, could you make this a validated/configuration error rather than a panic, and clarify the documentation?

The panic is reported in internal/operator/lifecycle.go at injectWALVolume (line 455), called during reconcilePod. Start there, then inspect the PluginConfig CRD schema and configuration documentation to determine whether storageConfig is optional. Reproduce with the supplied async Stanza and PluginConfig manifests; done means omission no longer causes a panic, with the expected validation or behavior documented.