fix(storenode): community fetches cap at 3 pages and skip empty-page processing (#21470-hf)

Run-4 device evidence (all prior #21470-hf fixes in): dead curated community
ids — whose descriptions are never on the store node — each cost a
~minutes-long 30-page run finalizing with fetchedEnvelopesCount=0 at cap-trip,
re-issued by client polling ~every 20s. The per-id backoff never suppresses
because each RUN outlasts its early backoff windows. The CPU engine:
shouldFetchNextPage force-runs Messenger.ProcessAllMessages on EVERY page,
including empty ones, and ProcessAllMessages walks the messenger's whole
pending backlog. During the legitimate channel backfill that means re-walking a
fat queue 30x per dead id, continuously (GC 67%, service 320-370%).

Two changes, both in protocol/messenger_store_node_request_manager*.go:

1. Split the page cap by request type. Community fetches now build from a
   dedicated community config capped at 3 pages
   (maxCommunityStoreNodeRequestPageCount) via
   buildCommunityStoreNodeRequestConfig; contact fetches keep the generic
   30-page default (buildStoreNodeRequestConfig). Store queries page
   newest-first (verified in go-waku history.go: PaginationForward unset =>
   proto3 default false => backward) and community descriptions are
   republished periodically, so a live community's description appears within
   the first pages; with the description-seen gate (6cd6ced) a hit stops the
   request anyway, so deeper paging can only ever chew empty/irrelevant
   history. The shared default is untouched — only the community construction
   site is tightened, and caller options can still override.

2. Skip the forced per-page ProcessAllMessages when the just-fetched page
   carried zero envelopes (shouldProcessStoreNodePage). The call only exists to
   flush THIS request's envelopes into the DB before the GetByID check; with
   zero envelopes there is nothing of ours to flush, so the backlog re-walk is
   pure waste. The DB check still runs, so a description delivered by a parallel
   channel-sync page is not missed.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
(cherry picked from commit cae6698)
(cherry picked from commit 0b2ee62d39aad5c0aa6134825365a9417723f1b7)

Author: alexjba

protocol/messenger_store_node_request_manager.go

@@ -75,7 +75,7 @@ func NewStoreNodeRequestManager(m *Messenger) *StoreNodeRequestManager {
 // Automatically waits for an available store node.
 // When a `nil` community and `nil` error is returned, that means the community wasn't found at the store node.
 func (m *StoreNodeRequestManager) FetchCommunity(ctx context.Context, communityID string, opts []StoreNodeRequestOption) (*communities.Community, StoreNodeRequestStats, error) {
-	cfg := buildStoreNodeRequestConfig(opts)
+	cfg := buildCommunityStoreNodeRequestConfig(opts)
 
 	m.logger.Info("requesting community from store node",
 		zap.String("community", communityID),
@@ -381,7 +381,21 @@ func (r *storeNodeRequest) shouldFetchNextPageUncapped(envelopesCount int) (bool
 	// Force all received envelopes to be processed. We keep the resulting
 	// response so a community request can tell whether this page actually
 	// carried a description for the target community (issue #21470-hf).
-	response := r.manager.messenger.ProcessAllMessages()
+	//
+	// Skip the walk entirely for an empty page: ProcessAllMessages traverses the
+	// messenger's whole pending backlog, but its only job here is to flush THIS
+	// page's envelopes into the DB before the GetByID check. With zero envelopes
+	// there is nothing of ours to flush, and during a channel backfill re-walking
+	// that fat queue on every empty page — to the cap, per dead id — is the CPU/GC
+	// storm behind the device overheat (issue #21470-hf). The DB check below still
+	// runs, so a description delivered by a parallel channel-sync page is not
+	// missed; only the redundant processing is dropped.
+	var response *MessengerResponse
+	if shouldProcessStoreNodePage(envelopesCount) {
+		response = r.manager.messenger.ProcessAllMessages()
+	} else {
+		logger.Debug("skipping ProcessAllMessages for empty store node page")
+	}
 
 	// Try to get community from database
 	switch r.requestID.RequestType {

protocol/messenger_store_node_request_manager_config.go

@@ -9,6 +9,19 @@ package protocol
 // full 31-day store-node window and burns CPU/battery on the device.
 const maxStoreNodeRequestPageCount = 30
 
+// maxCommunityStoreNodeRequestPageCount caps community fetches far more tightly
+// than the generic contact cap (issue #21470-hf). Store queries page newest-first
+// (verified in go-waku history.go: PaginationForward unset => proto3 default false
+// => backward) and community descriptions are republished periodically, so a live
+// community's description lands within the first pages; the description-seen gate
+// (6cd6ced1a) then stops the request on that hit. Deeper paging can therefore only
+// ever chew empty/irrelevant history — exactly the device failure mode: dead
+// curated ids each cost a ~minutes-long 30-page run finalizing with
+// fetchedEnvelopesCount=0. 3 pages keeps a healthy fetch (1-2 pages) untouched
+// while collapsing a dead-id run to a fraction of its former cost. Applied only at
+// the community construction site; the contact/default cap stays at 30.
+const maxCommunityStoreNodeRequestPageCount = 3
+
 type StoreNodeRequestConfig struct {
 	WaitForResponse   bool
 	StopWhenDataFound bool
@@ -89,6 +102,19 @@ func (c StoreNodeRequestConfig) gateNextPageByDescriptionSeen(fetchNext, descrip
 	return fetchNext, false
 }
 
+// shouldProcessStoreNodePage reports whether the forced per-page
+// Messenger.ProcessAllMessages should run for a page that carried envelopesCount
+// envelopes (issue #21470-hf). ProcessAllMessages walks the messenger's whole
+// pending backlog; the store-node pager only forces it to flush THIS request's
+// just-fetched envelopes into the DB before the GetByID check. A page with zero
+// envelopes has nothing of ours to flush, so processing it only re-walks the
+// (possibly fat) backfill queue for no gain — the CPU/GC amplification observed on
+// device. Skip it; the subsequent DB check still runs so a description delivered
+// by a parallel channel-sync page is not missed.
+func shouldProcessStoreNodePage(envelopesCount int) bool {
+	return envelopesCount > 0
+}
+
 type StoreNodeRequestOption func(*StoreNodeRequestConfig)
 
 func defaultStoreNodeRequestConfig() StoreNodeRequestConfig {
@@ -101,16 +127,36 @@ func defaultStoreNodeRequestConfig() StoreNodeRequestConfig {
 	}
 }
 
-func buildStoreNodeRequestConfig(opts []StoreNodeRequestOption) StoreNodeRequestConfig {
+// defaultCommunityStoreNodeRequestConfig is the base config for community fetches.
+// It matches the shared default in every field except the page cap, which is
+// tightened to maxCommunityStoreNodeRequestPageCount (issue #21470-hf).
+func defaultCommunityStoreNodeRequestConfig() StoreNodeRequestConfig {
 	cfg := defaultStoreNodeRequestConfig()
+	cfg.MaxPageCount = maxCommunityStoreNodeRequestPageCount
+	return cfg
+}
 
+func applyStoreNodeRequestOptions(cfg StoreNodeRequestConfig, opts []StoreNodeRequestOption) StoreNodeRequestConfig {
 	for _, opt := range opts {
 		opt(&cfg)
 	}
 
 	return cfg
 }
 
+// buildStoreNodeRequestConfig builds the config for a contact fetch (the generic
+// default, 30-page cap). Caller options are folded on top.
+func buildStoreNodeRequestConfig(opts []StoreNodeRequestOption) StoreNodeRequestConfig {
+	return applyStoreNodeRequestOptions(defaultStoreNodeRequestConfig(), opts)
+}
+
+// buildCommunityStoreNodeRequestConfig builds the config for a community fetch,
+// starting from the tighter community default (3-page cap). Caller options are
+// still folded on top and can override the cap (issue #21470-hf).
+func buildCommunityStoreNodeRequestConfig(opts []StoreNodeRequestOption) StoreNodeRequestConfig {
+	return applyStoreNodeRequestOptions(defaultCommunityStoreNodeRequestConfig(), opts)
+}
+
 func WithWaitForResponseOption(waitForResponse bool) StoreNodeRequestOption {
 	return func(c *StoreNodeRequestConfig) {
 		c.WaitForResponse = waitForResponse

protocol/messenger_store_node_request_manager_config_test.go

@@ -64,6 +64,67 @@ func TestStoreNodeRequestPageCap(t *testing.T) {
 	})
 }
 
+// TestCommunityStoreNodeRequestPageCap verifies that community fetches get a much
+// tighter page cap than contact fetches (issue #21470-hf). Store queries page
+// newest-first (go-waku history.go: PaginationForward unset = backward) and
+// community descriptions are republished periodically, so a live community's
+// description appears within the first few pages; with the description-seen gate
+// (6cd6ced1a) a hit stops the request anyway, so deep paging can only ever chew
+// empty/irrelevant history. The device evidence: dead curated ids each cost a
+// ~minutes-long 30-page run with fetchedEnvelopesCount=0 at cap-trip. Contact
+// fetches keep the generous 30-page cap; only the community construction site is
+// tightened, never the shared default.
+func TestCommunityStoreNodeRequestPageCap(t *testing.T) {
+	t.Run("community construction caps at 3 pages", func(t *testing.T) {
+		require.Equal(t, 3, maxCommunityStoreNodeRequestPageCount)
+		cfg := buildCommunityStoreNodeRequestConfig(nil)
+		require.Equal(t, maxCommunityStoreNodeRequestPageCount, cfg.MaxPageCount)
+	})
+
+	t.Run("contact construction keeps the generous 30-page cap", func(t *testing.T) {
+		require.Equal(t, 30, maxStoreNodeRequestPageCount)
+		cfg := buildStoreNodeRequestConfig(nil)
+		require.Equal(t, maxStoreNodeRequestPageCount, cfg.MaxPageCount)
+	})
+
+	t.Run("community construction is tighter than contact construction", func(t *testing.T) {
+		community := buildCommunityStoreNodeRequestConfig(nil)
+		contact := buildStoreNodeRequestConfig(nil)
+		require.Less(t, community.MaxPageCount, contact.MaxPageCount)
+	})
+
+	t.Run("community construction inherits the shared non-cap defaults", func(t *testing.T) {
+		cfg := buildCommunityStoreNodeRequestConfig(nil)
+		base := defaultStoreNodeRequestConfig()
+		require.Equal(t, base.WaitForResponse, cfg.WaitForResponse)
+		require.Equal(t, base.StopWhenDataFound, cfg.StopWhenDataFound)
+		require.Equal(t, base.InitialPageSize, cfg.InitialPageSize)
+		require.Equal(t, base.FurtherPageSize, cfg.FurtherPageSize)
+	})
+
+	t.Run("caller options still override the community cap", func(t *testing.T) {
+		cfg := buildCommunityStoreNodeRequestConfig([]StoreNodeRequestOption{WithMaxPageCount(7)})
+		require.Equal(t, 7, cfg.MaxPageCount)
+	})
+}
+
+// TestShouldProcessStoreNodePage verifies the decision that skips the forced
+// per-page Messenger.ProcessAllMessages when the just-fetched page carried zero
+// envelopes (issue #21470-hf). That call exists solely to flush THIS request's
+// envelopes into the DB before the GetByID check; with zero envelopes there is
+// nothing of ours to flush, yet ProcessAllMessages still walks the messenger's
+// whole pending backlog. During the legitimate channel backfill that means
+// re-walking a fat queue on every empty page — up to the page cap, continuously,
+// for each dead curated id — the CPU/GC storm seen on device (GC 67%, service
+// 320-370%). Skipping the walk on empty pages removes that amplification; the DB
+// check still runs (a parallel channel-sync page may have delivered the
+// description).
+func TestShouldProcessStoreNodePage(t *testing.T) {
+	require.False(t, shouldProcessStoreNodePage(0), "empty page has nothing of ours to flush")
+	require.True(t, shouldProcessStoreNodePage(1), "a page with envelopes must be processed")
+	require.True(t, shouldProcessStoreNodePage(50), "a full page must be processed")
+}
+
 // TestGateNextPageByValidationQueue verifies the decision that stops store-node
 // pagination for a community request once the community's description is already
 // in hand and only blocked on owner validation (issue #21470-hf). For a