# Error: resource ... was not successfully created by the Kubernetes API server: Server-Side Apply field conflict detected

## TL;DR
You switched providers and Kubernetes will not hand field ownership to the new one silently. Either adopt the resource with `pulumi state delete` + `pulumi import` under the new provider, or delete and recreate it.

## The error

```
error: resource "urn:pulumi:preview-pr-107::aphiria-com-infrastructure::kubernetes:batch/v1:Job::db-init-job" was not successfully created by the Kubernetes API server: Server-Side Apply field conflict detected.
The resource managed by field manager "pulumi-kubernetes-9b013652" had an apply conflict: Apply failed with 1 conflict: conflict with "pulumi-kubernetes-4afb3fc3": .spec.template.spec.containers[name="db-init"].args
```

## Fix it

1. Decide: adopt (no downtime) or recreate (downtime). For stateless workloads, recreate is simpler; for stateful ones, adopt.
   - Success check: you have picked one path deliberately.
2. To adopt: `pulumi state delete "[full URN]" --stack [stack]` (removes from state, keeps the live object), then `pulumi import [type] [name] [namespace]/[name] --stack [stack]` with the new provider configured.
   - Success check: `pulumi preview` shows no changes for the resource.
3. To recreate: `kubectl delete [type]/[name] -n [namespace]`, then `pulumi up`.
   - Success check: the resource is recreated under the new field manager.
4. Re-run `pulumi up`.
   - Success check: no more apply conflicts.

## When to use this
You hit this right after adding an explicit `Provider` resource (or changing provider configuration) on existing Kubernetes resources.

## When NOT to use this
Do not use this for RBAC `Forbidden` errors or webhook failures. Those are permissions and ordering, not field-manager ownership.

## Compatibility
Pulumi CLI 3.x, Pulumi Kubernetes provider v4.x, server-side apply enabled.

## Variants
- The same conflict naming Deployments, StatefulSets, or Services instead of Jobs
- `Apply failed with [n] conflicts` listing multiple field paths

## Root cause
Each provider instance is a distinct server-side-apply field manager. Kubernetes refuses silent ownership transfer between managers to prevent accidental stomps, so the new manager's apply conflicts with the old one's claimed fields.

## Edge cases
- `pulumi refresh` does not fix ownership; it only syncs observed state.
- Force-applying with `--force` server-side can stomp the old manager's fields. Prefer the import path for anything stateful.