epcis plugin V1 #22

MilanKomsa · 2026-01-14T08:29:42Z

No description provided.

packages/plugin-epcis/src/index.ts

packages/plugin-epcis/src/services/EPCISQueryService.ts

packages/plugin-epcis/src/services/EPCISValidationService.ts

+    }
+
+    // Validate against GS1 schema
+    const isValid = this.validateSchema(document);


In general, to fix this issue you should avoid enabling allErrors: true when validating untrusted input in production. That prevents Ajv from traversing the entire object and accumulating every possible error, limiting both CPU and memory usage by stopping at the first validation failure (or at least drastically reducing the error surface). If detailed error reporting is needed in non-production environments, you can still enable allErrors conditionally based on an environment flag.

The best fix here, without changing the observable behavior too much, is to make allErrors conditional on an environment variable (for example REST_DEBUG as in the background example, or a more plugin-specific variable). In production, where that variable is not set to a truthy value, Ajv will default to reporting only the first error, mitigating the DoS risk. In development, you still get the rich error list for debugging. Concretely, in packages/plugin-epcis/src/services/EPCISValidationService.ts, update the Ajv configuration in the constructor so that allErrors is not hard-coded to true but instead reads from process.env. No other code needs to change because Ajv’s public interface (compile, validate, and errors) remains the same; only the number of errors populated in this.validateSchema.errors will change.

To implement this, you only need to change the object literal passed to new Ajv in EpcisValidationService’s constructor. No new helper methods or imports are required, as process.env is available in Node.js by default. A typical pattern is:

this.ajv = new Ajv({ allErrors: process.env.REST_DEBUG === "true", strict: false, validateFormats: true, });

This keeps current behavior when REST_DEBUG=true (or whatever flag you choose) and disables multi-error collection otherwise.

Lexpeartha

Please also document new .env variable and add it to env.d.ts

MilanKomsa · 2026-01-16T14:40:26Z

Please also document new .env variable and add it to env.d.ts
What new .env variable?

there is no .env variable used in code

Balki-OriginTrail

code so beautiful, it made my cry

packages/plugin-epcis/src/index.ts

zsculac · 2026-01-20T13:30:38Z

packages/plugin-epcis/src/index.ts

+            } as any);
+          }
+          // Query publisher for asset status
+          const response = await fetch(`${publisherUrl}/api/dkg/assets/status/${encodeURIComponent(captureID)}`);


Note for the future, we should avoid calling our own server from that server. Instead we should expose the publisher plugin in context

Also, it would be wise to add some timeout here, so the request cannot hang forever.

will do next week

You don't have to rewrite the plugin to fit, it's a different task. This was just to keep in mind once it is rewritten.

Adding the timeout would be good though and it's quick

zsculac · 2026-01-20T13:33:28Z

packages/plugin-epcis/src/index.ts

+          console.error("[EPCIS Status] Error:", error);
+          res.status(500).json({
+            error: "Failed to get capture status",
+            message: error.message,


We should return generic messages to the user and log the specific message on the server to avoid leaking sensitive data

please elaborate

This returns a full backend error to the frontend which is generally not a good practice because it exposes the backend

while i agree, entire codebase is doing the same pattern, commented out the full error.message for now, but it's a repo wide problem which we should address in the future, will create a backlog task

Then we will slowly rewrite this in the codebase, we have to start somewhere :)

the message should still exist though. Sth generic like I mentioned in the first comment. Perhaps: "Internal server error".

Also please do this for all tools in this plugin, multiple tools still return error messages

packages/plugin-epcis/src/index.ts

zsculac · 2026-01-20T13:42:35Z

packages/plugin-epcis/src/index.ts

+          }
+
+          // Send to publisher
+          const result = await sendToPublisher(document, {


There should be some retries here and a fallback publishing using dkg.asset.create if the publisher plugin fails

this needs further discussion, will add it to backlog for rework

Why does it need further discussion? It's a general good practice to do this

packages/plugin-epcis/src/services/EPCISValidationService.ts

zsculac · 2026-01-20T14:11:04Z

packages/plugin-epcis/src/services/EPCISQueryService.ts

+    if (params.ual) {
+      return this.getEventByUal(params.ual);
+    }


if someone passes ual and some exclusive fields they are interested in they will still get everything back

Also we should do ual validation here and return a proper error. Currently if the ual is not valid it just returns prefixes.

You can check how this is done in dkg.js

commented out for now, isn't important for Friday demo, will be added to rework backlog

packages/plugin-epcis/src/index.ts

zsculac · 2026-01-20T14:20:52Z

packages/plugin-epcis/src/services/EPCISQueryService.ts

+  ${filterClauses.join('\n  ')}
+}
+ORDER BY DESC(?eventTime)
+LIMIT 100`;


Why is the limit hardcoded? This should not be up to us to decide

will be added to backlog for rework, not important for Friday

We should be thinking about the general repo and others who might be using the plugin too. They won't know about this limit and could spend much time debugging why they're not getting all events back

packages/plugin-epcis/src/index.ts

packages/plugin-epcis/src/services/EPCISQueryService.ts

github-advanced-security bot found potential problems Jan 14, 2026

View reviewed changes

MilanKomsa requested review from Lexpeartha, lupuszr and zsculac January 16, 2026 08:23

Lexpeartha previously requested changes Jan 16, 2026

View reviewed changes

MilanKomsa requested a review from Lexpeartha January 16, 2026 14:43

MilanKomsa requested a review from Balki-OriginTrail January 19, 2026 12:38

Balki-OriginTrail approved these changes Jan 19, 2026

View reviewed changes