Documentation / @etherfold/browser / serveIndexerHost

Function: serveIndexerHost()

serveIndexerHost<ABI, ProcessResultType, ProcessorConfig>(entry, access): IndexerHost<ABI, ProcessResultType, ProcessorConfig>

Defined in: packages/browser/src/host/serve.ts:318

OPEN A CONTAINER, DRIVE IT, AND ANSWER THE PORT.

Returns as soon as it is listening; opening the container and folding are under way by then and their failures are REPORTED through progress rather than thrown at a caller that has already been handed its host. That is the same choice the demotion path makes and for the same reason: a tab whose host failed to open must be able to ask why, and an exception raised inside a worker entry point reaches nobody.

IT STARTS INDEXING, because a host exists in order to fold and a worker entry point that had to say so twice would be a line every app writes identically. A tab turns it off and on again over the port (stopIndexing / startIndexing), and stopping the DRIVER never closes the CONTAINER: a stopped host still answers reads from the store its canonical generation folds into.

It is NOT the way to build a main-thread indexer

It is reached from a WORKER entry point (hostIndexerInThisWorker, hostIndexerInThisSharedWorker, both of which refuse to run in a document), and it is exported so a deployment can write a hosting shape this package does not ship. Calling it on the UI thread with a wire of your own would open a SECOND container beside createIndexerState, over the same store, and the first thing anybody would see is a writer being refused (ADR-0075): there is ONE main-thread path and it is that function, adapted (ADR-0082).

Type Parameters

ABI

ABI extends Abi

ProcessResultType

ProcessResultType

ProcessorConfig

ProcessorConfig = undefined

Parameters

entry

HostedIndexerSpec<ABI, ProcessResultType, ProcessorConfig>

access

HostAccess

Returns

IndexerHost<ABI, ProcessResultType, ProcessorConfig>