chore(deps): bump @ecency/sdk to 2.3.82

[feruzm]

Bumps @ecency/sdk from 2.3.81 to 2.3.82, the release of ecency/vision-web#1407 (issue ecency/vision-web#1403).

What it fixes

An account name is a fixed_string of 16 bytes, and hived asserts on the byte length while deserialising the argument, before it looks anything up. So an over-long value is not answered with "no such account", it is answered with

Assert Exception:in_len <= sizeof(data): Input too large: `<value>` (17) for fixed size string: (16)

That applies to plain reads, not only to broadcasts, because lookup_accounts, get_accounts and get_account_reputations all take an account_name_type. The SDK now resolves those to no matches instead of making the call, and get_accounts drops only the offending entries so one bad name no longer takes down the whole batch.

Worth knowing when writing account-name checks here: the limit is bytes, not characters. sebastián.bilbao is 16 characters and 17 bytes, вцпк33ппп43 is 11 characters and 18 bytes, and the node rejects both. A .length <= 16 check passes them.

Verification

• yarn.lock moves only the @ecency/sdk entry, nothing else re-resolved.
• Installed tree confirmed on 2.3.82, and the guard exercised through the published bundle rather than assumed:

"good-karma"        -> true
"aliveandthriving"  -> true    (exactly 16 bytes)
"aliveandthriving," -> false
"sebastián.bilbao"  -> false
"вцпк33ппп43"       -> false

• tsc --noEmit — 1 error, src/components/imageViewer/imageViewer.tsx(176,7), doubleTapScale not on Props. Pre-existing and unrelated: a clean install of development reports the identical single error at 2.3.80 and at 2.3.81. Still worth its own issue.

Summary by CodeRabbit

• Chores
  • Updated the Ecency SDK dependency to the latest compatible version.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 56a29a3d-c624-4afb-b4c2-99c9ac641cb5

📥 Commits

Reviewing files that changed from the base of the PR and between 23123a3 and 535fc85.

⛔ Files ignored due to path filters (1)

• yarn.lock is excluded by !**/yarn.lock, !**/*.lock

📒 Files selected for processing (1)

• package.json

---

📝 Walkthrough

Walkthrough

The package manifest updates the @ecency/sdk dependency constraint from ^2.3.81 to ^2.3.82.

Changes

SDK dependency update

Layer / File(s)	Summary
Update SDK version constraint package.json	The manifest updates the @ecency/sdk constraint from ^2.3.81 to ^2.3.82.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Poem

A bunny hops through versions bright,
The SDK gets a lift tonight.
From eighty-one to eighty-two,
One tiny change, precise and new.
Carrots cheer the update through!

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch bugfix/sdk-2-3-82

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[feruzm]

Correction to the verification section above: the claim that the imageViewer.tsx(176,7) typecheck error is pre-existing on development and worth its own issue is wrong. There is no bug, and no issue is needed.

doubleTapScale is a valid prop. patches/react-native-image-viewing+0.2.2.patch adds it, and it is applied by postinstall: npx patch-package. My verification installs all used yarn install --ignore-scripts, so the patch never landed and the prop was missing from Props. Running npx patch-package on the same tree:

typecheck ok: 0 errors (baseline 0)

Two related corrections:

• I described the error as reproducing "on a clean install of development", which read as independent confirmation. It was not. Every install shared the same --ignore-scripts flag, so it was the same artifact three times.
• The gate is node scripts/typecheck.js, a per-file comparison against tsc-baseline.json that fails only on regressions, not the bare tsc --noEmit I ran. The baseline is currently {"total": 0, "files": {}}.

CI was green throughout and was right. Nothing here needs following up.