issue: can we just put the guard inside storage so callers don't have to worry about this?

  async saveGasPrices(value: PartialMessage<GasPrices>): Promise<void> {
    if (!value.assetId) {
      value.assetId = this.stakingTokenAssetId;
    }
    
    await this.u.update({
      table: 'GAS_PRICES',
      value: new GasPrices(value).toJson() as Jsonified<GasPrices>,
    });
  }

This also doesn't require toPlainMessage which isn't entirely obvious from a glance how it serializes all the fields.

Actually, scratch that. We have to handle Um/alts differently. Something like this would work:

// used in main block processor loop
await this.saveGasPrices(compactBlock);

=====
// additional method

  private async saveGasPrices(block: CompactBlock) {
    const pricesToSave = [...block.altGasPrices];

    // Undefined field implies UM. Manually overriding as this is commonly not passed.
    if (block.gasPrices) {
      pricesToSave.push(
        new GasPrices({
          ...block.gasPrices,
          assetId: this.stakingAssetId,
        }),
      );
    }

    for (const price of pricesToSave) {
      if (!price.assetId) {
        console.warn(
          `BlockHeight: ${block.height}. No asset id for gas prices: ${JSON.stringify(price.toJson())}`,
        );
        continue;
      }
      await this.indexedDb.saveGasPrices(price);
    }
  }

callers should be explicit in intent. a well-typed parameter means callers don't have to worry - the type system will protect them.

unanticipated fallback behavior upon absent input (not default input, but literally absent input) is a greater source of concern.

plainmessage does not serialize fields. it represents the message type as a plain object. it is the same as the class instance, sans class instance methods. any class instance or object literal meeting the message type satisfies plainmessage.

this information is available from the docstring on the type and on the function. its existence is explained and its use in specific cases, and very specifically in db interaction, are recommended in bufbuild/connectrpc documentation.

it is the simplest way to express that a parameter requires data present for every field of the message type.

other options:

1. using the class type. led us to the present situation
2. using Required on the class type. would require non-message input
3. a literal redefinition of what the plainmessage type provides

If getAssetIdFromGasPrices is called with a GasPrices object where assetId is undefined, it will still return undefined.

hmm. getters are supposed to assert.

this solved the case on the testnet i was using but it's true the inner could be empty.

true correctness presumably requires much idb refactor and some helper methods.

i will add something here but larger interface work is out of scope

okay - if an AssetId class instance is present, it always contains a uint8array inner. so this

1. guards against the condition of an absent assetid (no inner, invalid keypath)
2. does not guard against the condition of a present assetid with default zero-length inner (bad inner, valid keypath)
3. does not guard against the impossible condition of a present assetid with an absent inner (can't happen by getter input type)

in the case of 3, the parameter of the getter requires a message class instance, and a class instance of gas prices will never have a present assetid with an absent inner. this is because children of the class instance emitted from a constructor are always other class instances, and so assetId may be absent and thus inner is undefined (case 1), or present and thus inner is defined of some length (case 2)

client method outputs use constructor and helper methods like fromJson use constructor

so the getter performs its purpose, but does not perform length verification. thus #1639

we need an additional conditional check before spreading the compactBlock.altGasPrices, something like

const altGasPrices = {
  ...toPlainMessage(altGas),
  assetId: getAssetIdFromGasPrices(altGas),
};

if (altGasPrices.assetId) {
  await this.indexedDb.saveGasPrices(altGasPrices);
} else {
  continue syncing without error
}

Yep, you're right. Updated my example above.