chore: add defensive error type checking for yup validationError handling

[Copilot]

The checkExchangePolicy function accessed e.inner without verifying the error type, causing potential runtime failures when non-Yup errors are thrown.

Changes

• Added extractValidationErrors helper - Validates error object structure before accessing inner property:

  • Verifies error is an object with an inner array
  • Explicitly extracts message, path, and value properties with type guards
  • Returns empty array for malformed errors

• Applied to both validation paths - Base validation (line 135) and bundle item validation (line 166) now use the helper

• Type-safe implementation - Uses TypeScript type guards instead of any, properly handles unknown error types

Example

// Before: Unsafe access
catch (e) {
  errors: e.inner?.map((error) => ({ ...error })) || []
}

// After: Defensive type checking
catch (e) {
  errors: extractValidationErrors(e)
}

The helper returns an empty errors array for non-Yup errors rather than throwing.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ levalleux-ludo
❌ Copilot
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Copilot]

Pull request overview

This PR hardens checkExchangePolicy error handling to avoid unsafe access to Yup ValidationError.inner, and updates fixtures/tests to cover unsupported metadata types.

Changes:

• Added an extractValidationErrors helper to defensively read Yup validation errors.
• Updated checkExchangePolicy to use the helper for both base offer validation and bundle item validation.
• Adjusted test fixtures and added a new test case/fixture for unsupported metadata.type.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
packages/core-sdk/src/offers/checkExchangePolicy.ts	Adds the defensive extraction helper and wires it into both validation catch paths.
packages/core-sdk/tests/check-exchange-policy.test.ts	Adds unsupported-metadata test and updates expectations for existing fixtures.
packages/core-sdk/tests/exchangePolicy/examples/invalidOffer6.json	Adds a new fixture used to validate unsupported metadata.type handling.
packages/core-sdk/tests/exchangePolicy/examples/invalidOffer2.json	Adjusts fixture metadata type to remain within supported schemas for “all errors” test.
packages/react-kit/src/components/offerPolicy/OfferPolicyDetails.tsx	Minor formatting change to the .find(...) predicate.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

extractValidationErrors can return entries with path/message set to "undefined" (or "[object Object]") because it coerces any existing property via String(...), even when the value isn’t a string (or is undefined). This can lead to confusing paths/messages and make downstream path matching unreliable. Consider guarding with typeof e.path === "string" / typeof e.message === "string" (or e.path != null) and otherwise using an empty string or a generic message.

Suggested change

	return {
	message: "message" in e ? String(e.message) : "",
	path: "path" in e ? String(e.path) : "",
	value: "value" in e ? e.value : undefined
	const err = e as { message?: unknown; path?: unknown; value?: unknown };
	return {
	message: typeof err.message === "string" ? err.message : "",
	path: typeof err.path === "string" ? err.path : "",
	value: "value" in err ? err.value : undefined

[Copilot]

In the base schema catch, errors is now set to extractValidationErrors(e). If the thrown error isn’t a Yup ValidationError (or has an empty/missing inner array), this will produce isValid: false with errors: [], which can mask failures and can be misinterpreted by consumers (e.g., UI logic that checks for specific error paths). Consider adding a fallback so that when no validation errors are extracted you still return a single error with a useful message (e.g., from e instanceof Error ? e.message : ...).

[Copilot]

Same issue in the bundle item validation catch: concatenating extractValidationErrors(e) can silently add no errors when a non-Yup error is thrown (or inner is empty), leaving result.isValid = false without any corresponding error details for that item. Consider using the same fallback behavior here as in the base validation path.

Suggested change

	result.errors = result.errors.concat(extractValidationErrors(e));
	const itemErrors = extractValidationErrors(e);
	if (itemErrors.length > 0) {
	result.errors = result.errors.concat(itemErrors);
	} else {
	result.errors = result.errors.concat({
	message:
	e instanceof Error
	? e.message
	: "Unknown bundle item validation error.",
	path: "metadata.items",
	value: item
	});
	}

[codecov]

Codecov Report

❌ Patch coverage is 83.33333% with 2 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (998-check-exchangepolicy-for-bundle@033ea70). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
...ackages/core-sdk/src/offers/checkExchangePolicy.ts	83.33%	2 Missing ⚠️

Additional details and impacted files

@@                          Coverage Diff                           @@
##             998-check-exchangepolicy-for-bundle    #1001   +/-   ##
======================================================================
  Coverage                                       ?   90.96%           
======================================================================
  Files                                          ?      176           
  Lines                                          ?     7236           
  Branches                                       ?     1346           
======================================================================
  Hits                                           ?     6582           
  Misses                                         ?      654           
  Partials                                       ?        0           

Flag	Coverage Δ
common	92.59% <ø> (?)
core-sdk	56.63% <83.33%> (?)
e2e	85.73% <75.00%> (?)
eth-connect-sdk	95.06% <ø> (?)
ethers-sdk	74.45% <ø> (?)
ipfs-storage	91.75% <ø> (?)
metadata	94.70% <ø> (?)
unittests	60.93% <83.33%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.