Panic deserializing charm container uid/gid during model migration

[rpbritton]

Filed by @canonical/solutions-qa. Root cause identified with AI assistance.

---

Description

Model migration panics whenever the migrating model contains a charm with explicit uid/gid on a container. The migration-master worker crashes on every restart until the migration times out.

Evidence

Log (source controller, exec 731461):

"migration-master" manifold worker returned unexpected error:
panic resulted in: interface conversion: interface {} is int64, not *int64

Fires 122ms after minion units report QUIESCE, during prechecks() → ModelInfo() → description.Deserialize(). Repeats with exponential backoff for the full 15-minute timeout.

Trigger — mysql-k8s rev 426 container metadata (from MongoDB state dump):

containers:
  mysql:
    uid: 584788
    gid: 584788
    resource: mysql-image

Older mysql-k8s revisions without uid/gid do not trigger the panic.

Root cause

In charmmetadata.go, importCharmMetadataContainer asserts *int64 but schema.Int() returns int64:

var uid *int
if valid["uid"] != nil {
    uid = int64ToIntPtr(valid["uid"].(*int64))  // panics: value is int64, not *int64
}
var gid *int
if valid["gid"] != nil {
    uid = int64ToIntPtr(valid["gid"].(*int64))  // same panic; also assigns to uid not gid
}

There are two bugs: the wrong type assertion (.(*int64) → .(int64)), and a copy-paste error where gid is assigned to uid.

Suggested fix

var uid *int
if valid["uid"] != nil {
    v := int(valid["uid"].(int64))
    uid = &v
}
var gid *int
if valid["gid"] != nil {
    v := int(valid["gid"].(int64))
    gid = &v
}

Note: int64ToIntPtr becomes dead code after this change.

Juju version

3.6.25 (using description@v11.0.1; bug also present in v10.0.0)

Upstream tracking: canonical/charm-integration-testing#734