Eloquent Relationship Caching: Why attach() Leaves Your Model Stale

You call attach() on a relationship, then immediately check that relationship in the next line. It returns empty. The data is in the database, but your model doesn’t know about it.

The Problem

Eloquent caches loaded relationships in memory. Once you access a relationship, Laravel stores the result on the model instance. Subsequent accesses return the cached version — even if the underlying data has changed.

// Load the relationship (caches in memory)
$article->assignedCategory;  // null

// Update the pivot table
$newCategory->articles()->attach($article);

// This still returns null! Cached.
$article->assignedCategory;  // null (stale)

The attach() call writes to the database, but the model’s in-memory relationship cache still holds the old value.

The Fix: refresh()

Call refresh() on the model to reload it and clear all cached relationships:

$newCategory->articles()->attach($article);

// Reload the model from the database
$article->refresh();

// Now it returns the fresh data
$article->assignedCategory;  // Category { name: 'Technology' }

refresh() re-fetches the model’s attributes and clears the relationship cache, so the next access hits the database.

refresh() vs load()

You might think load() would work:

// This re-queries the relationship
$article->load('assignedCategory');

It does work for this specific relationship, but refresh() is more thorough. It reloads everything — attributes and all eager-loaded relationships. Use load() when you want to reload a specific relationship. Use refresh() when the model’s state might be stale across multiple attributes.

When This Bites You

This typically surfaces in multi-step workflows where the same model passes through several operations:

// Step 1: Assign to initial category
$defaultCategory->articles()->attach($article);

// Step 2: Process the article
$result = $pipeline->run($article);

// Step 3: On failure, reassign to a different category
if (!$result->success) {
    $defaultCategory->articles()->detach($article);
    $reviewCategory->articles()->attach($article);

    $article->refresh();  // Critical! Without this, downstream code sees stale category.

    // Step 4: Log the transition
    $transition = new CategoryReassigned($article, $reviewCategory, $defaultCategory);
    $logger->record($transition);
}

Without the refresh(), any code that checks $article->assignedCategory after step 3 will still see the old category (or null). Event handlers, logging, validation — all get stale data.

The Pattern

Any time you modify a model’s relationships via attach(), detach(), sync(), or toggle(), and then need to read that relationship in the same request:

// Write
$model->relationship()->attach($relatedId);

// Refresh
$model->refresh();

// Read (now safe)
$model->relationship;

This is different from updating model attributes directly, where save() keeps the in-memory state in sync. Pivot table operations bypass the model’s state management entirely — they go straight to the database without telling the model.

Small habit. Prevents a class of bugs that are genuinely confusing to debug because the database looks correct but the code behaves like the data doesn’t exist.