Update the configure logic #48

dorezyuk · 2026-01-21T16:23:52Z

Currently we run init and diagnostics on every start up - until the successfully_configure flag is set. While being a simple logic this results in lots of unnecessary transactions (inti and diagnostics are transactions from the view of the payment provider backend and 1. cost money and 2. can overload the payment provider backend).

The idea is to query the payment terminal (status inquiry, which is fast and does not result in calls to the payment provider backend) and based on the return code to reason if we need to run the aforementioned commands.

The status inquiry returns the terminal_status_code, which is defined under chapter 11 of zvt.

Signed-off-by: Dima Dorezyuk <ddo@qwello.eu>

dorezyuk · 2026-01-23T07:46:41Z

zvt/src/constants.rs

    #[error("TID not activated")]
+    /// Note: This does **not** mean that we have to activate the tid on the
+    /// payment terminal side.
    TidNotActivated = 0x3a,


this has been verified with lavego

dorezyuk · 2026-01-23T07:47:29Z

zvt/src/constants.rs

+/// Messages as defined under chapter 11.
+#[derive(Debug, PartialEq, FromPrimitive, Clone, Copy, Error)]
+#[repr(u8)]
+pub enum TerminalStatusCode {


we act on only a fraction of the error codes right now - but we would need to observe which ones we really see from feig

dorezyuk · 2026-01-23T07:48:48Z

zvt_feig_terminal/src/feig.rs

+            constants::TerminalStatusCode::PtReady => {
+                log::debug!("Terminal is ready");
+            }
+            constants::TerminalStatusCode::ReconciliationRequired => {


note - this is not identical with the emails we receive regarding eod jobs - this would only fire if the pt itself thinks we need to run eod

hovinen

I might need you to walk me through some of these changes, since I'm not so familiar with all of the components involved.

hovinen · 2026-01-23T16:39:16Z

zvt_cli/src/main.rs

+}
+
+impl FromStr for StatusType {
+    type Err = String;


Given that this project is using anyhow anyway, would it make sense to use anyhow::Error here?

hovinen · 2026-01-23T16:42:13Z

zvt_cli/src/main.rs

+        match s.to_lowercase().as_str() {
+            "feig" => Ok(StatusType::Feig),
+            "zvt" => Ok(StatusType::Zvt),
+            _ => Err(format!("'{}' is not a valid StatusType (feig | zvt)", s)),


You could inline s in the format string: {s}. I see this elsewhere so I guess there's no concern about supporting older rustc version which don't have that yet.

hovinen · 2026-01-23T16:51:25Z

zvt_feig_terminal/src/feig.rs

    pub async fn configure(&mut self) -> Result<()> {
-        if self.successfully_configured {
-            return Ok(());
+        // Get the status inquiry so we can reason on the terminal_status_code.


It took me a while to understand this function. It seems that it's doing two distinct things: fetching the terminal status code via a kind of RPC and evaluating that to possibly issue some commands. What would you say about extracting those parts into separate, appropriately named functions to make the steps clearer?

hovinen · 2026-01-23T16:54:44Z

zvt_cli/src/main.rs

-        match response? {
-            CVendFunctionsEnhancedSystemInformationCompletion(data) => log::info!("{data:#?}"),
-            Abort(_) => bail!("Failed to get system info. Received Abort."),
+async fn status(


I'm having trouble understanding how these changes here map to what's in the PR description. This seems to be modifying the CLI tool to log some data in response to a command. How does that relate to the rest of the changes?

hovinen · 2026-01-26T10:22:47Z

zvt_cli/src/main.rs

+        StatusType::Zvt => {
+            let request = packets::StatusEnquiry {
+                password: Some(password),
+                service_byte: service_byte,


As discussed: since this can cause deserialization to fail for certain values, consider detecting those cases and printing at least a warning.

ydankner · 2026-01-26T12:01:48Z

zvt/src/constants.rs

    SystemError = 0xff,
 }
+
+/// Messages as defined under chapter 11.


Nit - to make the comment clearer, maybe add:
/// Messages as defined under chapter 11 of the ZVT specifications, under "Terminal Status Codes".

ydankner · 2026-01-26T12:11:37Z

zvt/src/sequences.rs

-    CompletionData(packets::CompletionData),
+    /// 2.55.5. The possible tags in the status enquiry correspond to the
+    /// ReceiptPrintoutCompletion.
+    CompletionData(packets::ReceiptPrintoutCompletion),


I'm not sure if I understand - until now did we misread status responses?

ydankner · 2026-01-26T12:18:09Z

zvt_cli/src/main.rs

+            };
+
+            let mut stream = sequences::StatusEnquiry::into_stream(&request, socket);
+            while let Some(response) = stream.next().await {


Can we also get an Abort here from the stream? Would we likewise want to bail if we get it?

ydankner · 2026-01-26T12:38:39Z

zvt_feig_terminal/src/feig.rs

+    /// We're doing the following based on the terminal status code:
+    /// * If PtReady - return
+    /// * If ReconciliationRequired - run end-of-day
+    /// * If InitialisationRequired or DiagnosisRequired - set terminal id and run emv diagnostics


It's incomplete here - If InitialisationRequired or DiagnosisRequired or TerminalActivationRequired - set terminal id and run emv diagnostics, and initialize the terminal.

ydankner · 2026-01-26T12:42:55Z

zvt_feig_terminal/src/feig.rs

+
+        match status {
+            constants::TerminalStatusCode::PtReady => {
+                log::debug!("Terminal is ready");


Nit - I think this can be info, since this only happens on new and reconnect

ydankner · 2026-01-26T12:43:50Z

zvt_feig_terminal/src/feig.rs

+                    terminal_status_code = Some(completion_data.terminal_status_code);
+                }
+                other => {
+                    log::debug!("{other:#?}");


If this is unexpected behavior, I think this can likewise be info / warning.

ydankner · 2026-01-26T12:53:08Z

zvt_feig_terminal/src/feig.rs

+            }
+            constants::TerminalStatusCode::ReconciliationRequired => {
+                info!("Reconciliation required, running end of day");
+                self.end_of_day().await?;


We wouldn't know a failure occurred here, since end_of_day doesn't log failure. Do we want to add some failure log there, here, or log the error when calling configure? Same goes for failure of set_terminal_id, initialize, and run_diagnosis below.

Better yet - since if this function fails we won't have a working PT on a pole, better log it in the calling function and add an alert for this failure to track it

ydankner · 2026-01-26T18:18:30Z

zvt_feig_terminal/src/feig.rs

+                self.set_terminal_id().await?;
+                self.run_diagnosis(packets::DiagnosisType::EmvConfiguration)
+                    .await?;
+                self.initialize().await?;


Nit - We can safely return after this line, we don't need to check if the TID was changed again since we've just set it.

hovinen

LGTM based on our discussion yesterday. Please see also my comments.

Dima Dorezyuk added 2 commits January 21, 2026 17:22

Update the configure logic

bac1f0d

Signed-off-by: Dima Dorezyuk <ddo@qwello.eu>

remove the tid not initialized handling

a173fd5

Signed-off-by: Dima Dorezyuk <ddo@qwello.eu>

dorezyuk force-pushed the feat/update_configure_logic branch from 7d4e408 to a173fd5 Compare January 23, 2026 07:40

dorezyuk commented Jan 23, 2026

View reviewed changes

hovinen reviewed Jan 23, 2026

View reviewed changes

hovinen reviewed Jan 26, 2026

View reviewed changes

ydankner approved these changes Jan 26, 2026

View reviewed changes

ydankner reviewed Jan 26, 2026

View reviewed changes

hovinen approved these changes Jan 27, 2026

View reviewed changes

Update the configure logic #48

Are you sure you want to change the base?

Update the configure logic #48

Uh oh!

Conversation

dorezyuk commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hovinen left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hovinen left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

dorezyuk commented Jan 21, 2026 •

edited

Loading