linera-io/linera-protocol · error
Application parameters must be deserializable
Error message
Application parameters must be deserializable
What it means
ServiceRuntime::application_parameters lazily fetches the creation-time parameters bytes from the host and parses them with serde_json::from_slice::<Application::Parameters>. The expect panics when the stored parameters JSON cannot be decoded into the service's current Parameters type — typically because the application was created with no/different parameters, or the Parameters type changed after publication.
Source
Thrown at linera-sdk/src/service/runtime.rs:72
pub fn key_value_store(&self) -> KeyValueStore {
KeyValueStore::for_services()
}
/// Returns a storage context suitable for a root view.
pub fn root_view_storage_context(&self) -> ViewStorageContext {
ViewStorageContext::new_unchecked(self.key_value_store(), Vec::new(), ())
}
}
impl<Application> ServiceRuntime<Application>
where
Application: Service,
{
/// Returns the application parameters provided when the application was created.
pub fn application_parameters(&self) -> Application::Parameters {
Self::fetch_value_through_cache(&self.application_parameters, || {
let bytes = base_wit::application_parameters();
serde_json::from_slice(&bytes).expect("Application parameters must be deserializable")
})
}
/// Returns the ID of the current application.
pub fn application_id(&self) -> ApplicationId<Application::Abi> {
Self::fetch_value_through_cache(&self.application_id, || {
ApplicationId::from(base_wit::get_application_id()).with_abi()
})
}
/// Returns the chain ID of the current application creator.
pub fn application_creator_chain_id(&self) -> ChainId {
Self::fetch_value_through_cache(&self.application_creator_chain_id, || {
base_wit::get_application_creator_chain_id().into()
})
}
/// Returns the description of the given application.View on GitHub (pinned to 6c226ddcb3)
Solutions
- Publish the application again with valid JSON for the current Parameters type (linera publish-application ... --parameters '<json>') so on-chain creation parameters match
- Give every Parameters field a #[serde(default)] or make it Option<T> so empty/legacy parameter objects still decode
- Verify the --parameters string is valid JSON and round-trips through Parameters' own Serialize before publishing
- If Parameters is genuinely absent, declare it as a unit-like type (struct Parameters;) or Option<Parameters> instead of a struct with required fields
Example fix
// before: required field panics when app was created without parameters
#[derive(Serialize, Deserialize)]
struct Parameters { admin: AccountOwner }
// after: defaulted field decodes even for legacy instantiations
#[derive(Serialize, Deserialize)]
struct Parameters {
#[serde(default)]
admin: Option<AccountOwner>,
} Defensive patterns
Strategy: validation
Validate before calling
// Validate creation parameters before publishing.
fn check_parameters(json: &str) -> Result<(), serde_json::Error> {
serde_json::from_str::<Parameters>(json).map(|_| ())
} Prevention
- Always pass --parameters with JSON produced by serializing your own Parameters type
- Derive Default where sensible and add #[serde(default)] to Parameters fields so legacy apps keep loading
- Add a unit test that decodes '{ }' (or the empty-parameters form) into Parameters
- After changing Parameters, treat already-deployed apps as needing re-publication
When it happens
Trigger: Instantiating the service for an application whose creation parameters were empty or of a different shape than Application::Parameters (e.g. Parameters expects required fields but the app was created with --parameters '{}' or none), or running a service module newer than the one that created the application.
Common situations: Deploying a new Parameters struct (new required field) while existing applications were created with the old JSON; forgetting to pass --parameters when publishing; publishing with parameters serialized from a different serde configuration (field renaming, tagged enums); pointing a service at an application created on another network.
Related errors
- Failed to deserialize service response
- Failed to deserialize query response from application
- Failed to deserialize instantiation argument {argument:?}
- Query {argument:?} is invalid and could not be deserialized
- Application parameters must be deserializable
AI-assisted analysis of linera-io/linera-protocol@6c226ddcb3 (2026-08-22).
Data as JSON: /api/errors/0841f6616d78678c.
Report an issue: GitHub.