Redundant S3 reads during write_note and edit_note add ~1s latency

[phernandez]

Problem

Both edit_note and write_note read the same file from S3 multiple times within a single tool call. The content was just written — it should be passed through in-memory instead of re-fetched.

edit_note: 3 S3 reads of the same file

From trace 019d49a39cffc28f742bca0fd6a8793f (10.4s edit_note):

Step	S3 Op	Duration	Purpose
entity_service.edit.read_file	get_object	0.40s	Read current content to apply edit operation
search.index.read_content	get_object	0.32s	Re-read to build search index rows
api.knowledge.edit_entity.read_content	get_object	0.28s	Re-read for API response

Total wasted: ~0.6s on redundant S3 round-trips.

The write path also has this pattern:

• entity_service.edit.write_file → S3 put (0.43s) — write the file
• Then immediately reads it back twice

write_note: 4-5 S3 calls per write

Aggregated data (40 write_note calls today):

• Average 4.1 S3 calls per write_note
• Average 2.4 ASGI round-trips per write_note

Similar pattern: write file, then re-read for search indexing and response building.

resolve_permalink in create_entity: 1.1s avg

entity_service.create.resolve_permalink averages 1.1s (P95: 2.4s) across 49 calls. This likely involves sequential DB lookups that could be optimized or cached since the entity was just created.

Aggregated Evidence (last 12h, 60+ calls each)

Span	Avg	P50	P95	Calls
edit_entity.write_entity	3.25s	3.21s	4.53s	82
create_entity.write_entity	3.34s	3.13s	5.22s	52
entity_service.edit.write_file (S3 put)	0.47s	0.35s	1.29s	81
entity_service.edit.read_file (S3 get)	0.42s	0.33s	1.20s	82
entity_service.create.write_file (S3 put)	0.37s	0.33s	0.53s	49
entity_service.create.resolve_permalink	1.12s	0.82s	2.41s	49

Proposed Fix

1. After writing a file to S3, keep the content in memory and pass it to the search indexer and response builder instead of re-reading from S3
2. Investigate resolve_permalink — may be doing unnecessary DB lookups for freshly-created entities

This would save ~0.6-1s per edit/write operation.

[claude]

Claude finished @phernandez's task in 2m 19s —— View job

---

Issue Triage

• Gather context and read issue
• Read relevant source code
• Classify issue type, priority, component, complexity
• Check for duplicate issues
• Add labels
• Post triage summary

---

Analysis

Type: Performance Enhancement
Priority: Medium — measurable ~0.6–1s latency regression per operation on cloud, but not blocking
Component: Cloud + MCP tools (write_note, edit_note)
Complexity: Medium — service layer changes needed to thread content in-memory through the write pipeline

Labels added: enhancement, cloud

---

Code Investigation

I traced the write_note / edit_note call chains:

edit_note (fast mode, default):

1. file_service.read_file() — reads current content to apply the edit ✓ necessary
2. file_service.write_file() — writes modified content
3. read_file_content() — re-reads to build API response ← redundant
4. Background reindex_entity task: read_file_content() for markdown parse ← redundant
5. Background reindex_entity task: checksum read ← redundant

write_note (fast mode):

1. file_service.write_file() — writes new content
2. read_file_content() — re-reads for API response ← redundant
3. Background reindex_entity: two more reads ← redundant

The content is in-memory immediately after write_file() — it just needs to be threaded through to the response builder and the reindex task instead of re-fetching.

---

Related Issues

• upsert_entity takes 1.8s avg for single entity writes on cloud #709 — upsert_entity DB latency (1.8s avg) — different root cause (sequential Neon PostgreSQL round-trips for observation/relation diffs). Complementary fix; together they'd address the full ~3–4s write path overhead.
• Search hydrate_results N+1 query causes 3s+ latency on cloud #707 — Search hydrate_results N+1 query — separate issue, read path.

Not a duplicate of any existing issue.

---

Proposed Approach (confirming the issue's suggestion)

The fix aligns with what's proposed:

1. After write_file(), capture the written content and checksum in memory.
2. Pass content to response builder (read_file_content() call eliminated).
3. Pass content to reindex_entity via the task payload, so it can skip the re-read.

The resolve_permalink slowness (1.1s avg) mentioned in the issue is likely accounted for by the DB network latency to Neon — the code itself does lightweight indexed queries. That said, it could be batched with the initial entity lookup to save a round-trip.