Investigation: Fren Pet training camps not starting for pets 83633, 83632, 83608, and 83626

Investigation time: 27 September 2026, 23:10–23:14 UTC
Networks/services checked: Fren Pet production indexer/API, Fren Pet AI production API/UI, Base mainnet
Operator contract: 0x065bf5a7AF15c52C91353990CC8F3d97A1595CE7

Executive conclusion

All four pets have the same class of failure.

The Fren Pet game believes each pet is eligible to begin both an attack and a defense camp. Each has hundreds of wins, no camp level, no active camp, and trainingCanStartAtk: true. Meanwhile, Fren Pet AI is continuing to execute other actions successfully for the same pets. Its public operation feed contains recent successful bonks (and a successful wheel reveal for every pet), but no startTrainAttack, stopTrainAttack, startTrainDefense, or stopTrainDefense operation for any of the four.

The proven proximal cause is therefore in Fren Pet AI's training scheduling/configuration path, before a training transaction is submitted: eligible pets are not being selected/enqueued for startTrainAttack. This is not a failure of the win prerequisite, a pet-specific game-state lock, an exhausted gas account, a stopped agent, or a reverted on-chain start transaction.

The available public evidence does not expose the authenticated stored configuration or server source, so it does not prove the exact faulty line. The two leading internal root causes are (1) the scheduler is reading these pets' stored training value as disabled/stale/missing even though the UI reported “Only ATK”, or (2) the training eligibility predicate/action builder is dropping these records. Logging the scheduler decision for these four IDs will distinguish them immediately. Treating a successful configuration response as sufficient proof that the worker consumed the configuration is an underlying observability/design defect.

Results by pet

The snapshot below is from a single GraphQL response from https://api.pet.game, indexed through Base block 51,880,646 (block timestamp 1790550639, 27 September 2026 23:10:39 UTC).

Pet	Wins	ATK / DEF	ATK camp level	DEF camp level	Camp active	API says ATK can start	Recent Fren Pet AI evidence	Assessment
83633	382	22 / 24	0	0	false	true	successful bonk at 1790550727; wheel at 1790538843	scheduler omission
83632	203	21 / 21	0	0	false	true	successful wheel at 1790538843; recent game attack at 1790535301	scheduler omission; lower bonk frequency is not a camp blocker
83608	344	21 / 21	0	0	false	true	successful bonk at 1790548087; wheel at 1790538843	scheduler omission
83626	230	15 / 20	0	0	false	true	successful bonk at 1790550127; wheel at 1790538843	scheduler omission

There is no evidence that one pet has a different training problem. Pet 83632 is less recently active in battle than the others, but its automation performed a wheel action, its game status is the same (status: 2), it is not training, and the game independently returns trainingCanStartAtk: true. That difference does not explain failure to start a camp.

Evidence and reasoning

1. Every game-side prerequisite represented by the API is satisfied (fact)

For all four records, the production game API returned:

• trainingAtk: 0 and trainingAtkUntil: 0;
• trainingDef: 0 and trainingDefUntil: 0;
• trainingActive: false;
• trainingCanStartAtk: true and trainingCanStartDef: true;
• a live/active common status value of 2; and
• the same owner, 0x2978E6219D540e8E8Cff994bf88Ad68782333Eb2.

The documented camp progression requires 10 wins for level 1, then 20 more for level 2, 30 more for level 3, and so on (Fren Pet gameplay documentation). The cumulative wins required through level n are therefore 5 × n × (n + 1). Even without relying on the API's explicit booleans, the listed win totals permit at least levels 8, 5, 7, and 6 respectively. The claimed prerequisite is not merely met once; it is met repeatedly.

This is primary production-state evidence. The documentation supplies the rule; the API supplies the authoritative indexed state.

2. The agents and operator are functioning for these pets (fact)

The public Fren Pet AI endpoint /api/operations?afterTimestamp=0&ids=83633,83632,83608,83626 returned recent operations with state: "success" for the pets. Examples include:

• pets 83633, 83608, and 83626: multiple successful bonkReveal operations;
• all four pets: wheelReveal in transaction 0x090e…83a4;
• pet 83626: a successful bonk in 0x1078…e03.

Thus registration, ownership/authorization, operator execution, and at least some gas funding are working. A system-wide worker outage is contradicted by the operation stream.

3. No training action is being submitted (fact, within the public feed's retention window)

The same operation response contains no training action for any target pet. Fren Pet AI's deployed client recognizes the action names startTrainAttack, stopTrainAttack, startTrainDefense, and stopTrainDefense and renders them in its live activity view. This can be inspected in the deployed /pets JavaScript referenced by https://frenpet.ai/pets. The client also exposes the persisted configuration choices as disabled, atk, def, weakest, and fastest, displaying atk as Only ATK.

This absence matters because a reverted attempt should still have an attempted/failed operation or transaction to inspect. Instead, other actions are present and successful while training is absent. The strongest supported interpretation is “not scheduled,” rather than “scheduled and rejected by the game.”

Limit: the public operations endpoint returned the most recent 25 matching operations and exposes no documented backward-pagination parameter. Absence is therefore established for that returned window, not for all historical database rows. The zero on-chain/indexed camp state proves that no historical start ever successfully took effect.

4. Configuration cannot be independently verified anonymously (fact)

GET https://frenpet.ai/api/user/config/{petId} returned HTTP JSON {"error":"Unauthorized"} for every target ID. Consequently this investigation accepts the task owner's statement that all four were configured as attack training, but cannot independently read the stored server-side values.

The deployed client has a noteworthy failure-masking behavior: if fetching configuration fails, it catches the error and substitutes a default whose training field is "disabled". This affects what the UI can show and can conceal a read/auth/data failure. It does not by itself prove that the backend worker uses the same fallback, but it is a concrete underlying factor and a likely route by which intended atk configuration and effective configuration can diverge.

Root-cause statement

Established

1. Immediate failure: Fren Pet AI does not dispatch startTrainAttack for these eligible pets.
2. Failure boundary: the defect is upstream of the Fren Pet Diamond training call, inside effective configuration retrieval, eligibility selection, or action construction/enqueueing.
3. Commonality: the same boundary and symptom apply to all four pets. There is no evidence of a separate issue for one of them.
4. Contributing design issue: neither the UI nor public operation history exposes “evaluated but skipped” decisions, and the UI silently falls back to training: "disabled" on config-read failure. This makes a persisted/effective config mismatch look like successful configuration.

Strong inference, not yet proven

The most likely exact defect is an effective-config mismatch: the UI wrote or displayed atk, while the worker sees disabled, missing, stale, or an unrecognized value. This parsimoniously explains four pets under one owner failing identically while unrelated actions continue. A shared bug in the worker's training predicate is the other plausible explanation.

There is no evidence here for an ID-width overflow. All four IDs exceed 65,535, but successful wheel/bonk processing of those same IDs shows the platform and operator generally handle them; only an inspection of training-specific casts could establish such a narrower bug.

Unanswered

• What exact configuration row/value/version does the worker load for each ID?
• Does a scheduler trace say training_disabled, not_eligible, already_training, or an exception?
• Was the configuration POST committed to the same database/environment read by the worker?
• Does the worker compare against "attack" while the current UI stores "atk", or otherwise use an outdated enum/schema?
• Are failed scheduler evaluations retained anywhere outside the public operation endpoint?

Recommended repair

1. Immediate recovery: authenticated staff should read the four raw configuration rows and normalize each training value to the worker's canonical attack enum (the current deployed UI writes atk). Re-save them, invalidate worker/config caches, and manually enqueue one startTrainAttack for each pet. Confirm the game API changes to trainingActive: true and records a nonzero attack-training end time.
2. Fix the worker contract: validate configuration against one shared enum/schema at write and read time. Reject unknown/missing values instead of coercing them to disabled. Add a migration for legacy values such as attack/Only ATK if they exist.
3. Instrument selection: for every eligible registered pet, record a decision with pet ID, config revision, game snapshot/block, canStartTrainingAtk, chosen action, or an explicit skip reason. Alert when training=atk && canStartTrainingAtk=true && trainingActive=false persists through two scheduler cycles.
4. Remove silent UI fallback: show configuration fetch/auth failure as an error. Do not render or save disabled as if it were the existing setting when the read failed.
5. Regression test: seed four pets with IDs above 65,535, zero training levels, and wins around each threshold; set training=atk; run a scheduler cycle; assert one start is enqueued per pet, then no duplicate while active, and a stop is enqueued at expiry. Include a mixed batch where other actions continue.

If the raw rows already contain canonical atk and the worker trace confirms it read them, move directly to the eligibility predicate: compare the worker's input fields with the current game fields (trainingCanStartAtk in the indexer versus canStartTrainingAtk in the Diamond's full-info tuple). A stale field-name/schema mapping would yield exactly this “game says true, worker never submits” behavior.

Reproduction details

Game-state query used (POST to https://api.pet.game, Content-Type: application/json):

query {
  p83633: pet(id: 83633) { id name status owner winQty petWins attackPoints defensePoints trainingAtk trainingAtkUntil trainingDef trainingDefUntil trainingCanStartAtk trainingCanStartDef trainingActive createdAt lastAttacked }
  p83632: pet(id: 83632) { id name status owner winQty petWins attackPoints defensePoints trainingAtk trainingAtkUntil trainingDef trainingDefUntil trainingCanStartAtk trainingCanStartDef trainingActive createdAt lastAttacked }
  p83608: pet(id: 83608) { id name status owner winQty petWins attackPoints defensePoints trainingAtk trainingAtkUntil trainingDef trainingDefUntil trainingCanStartAtk trainingCanStartDef trainingActive createdAt lastAttacked }
  p83626: pet(id: 83626) { id name status owner winQty petWins attackPoints defensePoints trainingAtk trainingAtkUntil trainingDef trainingDefUntil trainingCanStartAtk trainingCanStartDef trainingActive createdAt lastAttacked }
  _meta { status }
}

The API is a GraphQL POST service, so its root link opens the GraphQL playground rather than a durable per-query page. The query above makes the reported snapshot independently reproducible. Values are time-sensitive and may change after remediation; the block number anchors the observation.

Confidence

• High: eligibility, zero camps, common symptom, ongoing non-training automation, and localization to pre-submission scheduling.
• Moderate: effective configuration mismatch as the most likely exact internal defect.
• Not established from public access: the precise server-side line or whether config storage versus the training predicate is the final fault.