Profile serialization crashes when LLM returns structured bio/persona fields

[ygh1254]

Summary

When profile generation returns structured JSON objects for fields like bio, persona, or country, MiroFish can fail during profile serialization before config generation starts.

Reproduction context

Observed on a live run with:

• simulation_id: sim_e69a946b6158
• graph_id: mirofish_a39b5f10127f4744
• entities_count: 91
• status in state file: failed
• error in state file: slice(None, 150, None)

Traceback

File "backend/app/services/simulation_manager.py", line 361, in prepare_simulation
  generator.save_profiles(
File "backend/app/services/oasis_profile_generator.py", line 1189, in save_profiles
  self._save_reddit_json(profiles, file_path)
File "backend/app/services/oasis_profile_generator.py", line 1296, in _save_reddit_json
  "bio": profile.bio[:150] if profile.bio else f"{profile.name}",
KeyError: slice(None, 150, None)

Root cause

OasisAgentProfile declares bio / persona as strings, but the profile generation path does not enforce that contract.

Current flow:

• LLM output is parsed with json.loads(...)
• only presence/truthiness of result["bio"] and result["persona"] is checked
• values are passed through directly into OasisAgentProfile
• serializer later assumes they are strings ([:150], .replace(...), concatenation)

In the failed run, partially written reddit_profiles.json already contained mixed types:

• bio as dict in at least 2 profiles
• persona as dict in at least 31 profiles
• country as list in at least 12 profiles

So the crash is not strictly a prompt-length issue; it is a type-normalization bug between profile generation and serialization.

Impacted code

• backend/app/services/oasis_profile_generator.py
  • generate_profile_from_entity(...)
  • _generate_profile_with_llm(...)
  • _save_twitter_csv(...)
  • _save_reddit_json(...)

Suggested fix

Normalize mixed LLM outputs before building OasisAgentProfile, and add defensive coercion again before serialization.

Examples:

• coerce dict/list bio/persona to strings
• join list country values into a single string
• flatten structured interested_topics

Why this matters

Even when the simulation graph and profile generation complete, the run can still fail during save/serialization, leaving the simulation in a failed state before config generation / run starts.

Verified local fix

A minimal patch that:

• normalizes bio/persona/country/profession/interested_topics on OasisAgentProfile construction
• re-coerces values in _save_twitter_csv() and _save_reddit_json()

was able to serialize a reproduction object with:

• bio as dict
• persona as dict
• country as list

without crashing.

[dosubot]

Hi @ygh1254! I'm Dosu and I’m helping the MiroFish team.

Your analysis is spot on. Looking at the code, the root cause is exactly as you described — the OasisAgentProfile dataclass uses type hints but Python dataclasses don't enforce types at runtime.

The current validation in _generate_profile_with_llm() only checks for presence/truthiness of bio and persona, not their types:

if "bio" not in result or not result["bio"]:
    result["bio"] = entity_summary[:200] if entity_summary else f"{entity_type}: {entity_name}"
if "persona" not in result or not result["persona"]:
    result["persona"] = entity_summary or f"{entity_name}是一个{entity_type}。"

This allows a dict or list to pass through since they're truthy values.

The only field that currently gets normalized is gender via _normalize_gender(), and that's applied during serialization rather than at profile creation.

This isn't an isolated pattern — Issue #135 showed a similar type mismatch issue where the LLM generated ontology attributes as a string list instead of a dict list, causing TypeError: string indices must be integers, not 'str'.

Your suggested fix approach (normalize at OasisAgentProfile construction + defensive coercion during serialization) aligns well with the existing pattern. A __post_init__ method on the dataclass could handle the construction-time normalization, and extending the serialization methods would provide the defensive layer.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}