Hi everyone, I’m seeing an intermittent issue related to variant stock level updates not immediately reflecting on the storefront. When stock levels are updated via

Spree::StockMovement

(triggered from a background job), the DB values update correctly, but the frontend continues to display outdated stock for a few minutes. Updating stock manually through the admin panel reflects instantly, so it seems tied to how the cache invalidation is triggered. What I’ve observed: •

on_hand

updates are correct in the DB • StockMovement callbacks fire as expected • Variant cache is not always invalidated • Manual cache clear fixes the issue immediately • Occurrence rate is roughly 20–30% This isn’t blocking anything major, but it can lead to temporary mismatches in displayed inventory, so I wanted to check if anyone else has encountered this behavior or if there are recommended approaches to ensure cache invalidation on variant stock changes. Any insights would be appreciated. Thanks!

Hey @Lumino Astra 👋 This seems like a caching issue like you already identified. I am curious if you have compared how the stock movement that is being persisted in the background job differs from the one created in the admin controller. If you weren't creating stock movements and instead updating the stock items with

update_column

I could see how this would happen, however the way the cache invalidation works is by propagating the touch to the variant level. You can follow the chain here 1. After stock movement is created the stock item quantity is updated in this `after_create` callback 2. In turn the stock item update will result in a touch to the associated variant in these callbacks There are a couple of things I would check 1. The variants in question are configured to track inventory 2. What the value of the

Spree::Config.inventory_cache_threshold

is and if this isn't preventing certain updates from propagating to the variant 3. Ensure your cache keys in your frontend are correctly referencing the variant

updated_at

Good points — here’s what I’ve checked so far: • Stock movements: Both the admin action and the background job create

Spree::StockMovement

normally. No

update_column

calls on

stock_items

, so the callback chain should be identical. I’ll compare logs side-by-side to confirm if anything differs at creation time. • Inventory tracking: All affected variants have

track_inventory

enabled. • `inventory_cache_threshold`: Currently set to the default (

0

), so even small changes should propagate the

touch

to the variant. • Frontend cache keys: The storefront uses

variant.updated_at

in its keys. In the cases where stale stock appears,

updated_at

doesn’t always reflect the background-job stock movement. Since it only happens ~20–30% of the time, I’m suspecting a race condition or timing issue with concurrent stock movements or cache writes. I’m adding detailed logging around the callbacks to try to get a reproducible case. Just validating config first as you suggested. Thanks again for pointing me in the right direction! 🙏

It sounds like you are on the right track! I would check that you also don't have some nested caching where the inner cache is expiring, but it doesn't have an effect due to an outer cache, or something like that. Caching issues are always hard to track, but it sounds like you have the right idea and are going down the steps to track where/why this is happening. I would also maybe confirm that you don't have any caching of queries in the backend that is causing the updated variant timestamps to not be reflected.

Thanks, Chris Really appreciate the pointers! 🙏 Yeah, I’ll take another look at the caching setup. It’s possible there’s some outer-layer cache sticking around even when the inner one expires. I’ll also check if the backend might be reusing a cached query somewhere, which could explain why the updated timestamps don’t always show up immediately. Once I confirm that the

variant.updated_at

is getting touched properly from the background job, I’ll dig into the frontend caching to see if it’s occasionally missing the invalidation. Thanks again, this definitely helps me narrow things down. 🙌

Glad I could help! If you still think this may be an issue in Solidus don't hesitate to file a ticket and we can investigate this further!