WeChat Article Metrics Scraper — 公众号文章阅读/点赞/分享/收藏数
Pricing
$0.06 / actor start
📊 WeChat Article Metrics | The read and share counts behind an article Fetch public interaction metrics for any WeChat Official Account article: read count, like count, share count, collect count, comment count and star count. Two engines — a full-metrics default and a lighter h5 mode.
LIMITED_PERMISSIONS — how Apify's automated QA and every API-triggered run
starts an Actor — opening the store is refused with HTTP 403
(KeyValueStoreCollectionClient.getOrCreate, path /v2/key-value-stores).
That call sat in a || fallback chain and was never inside a try/catch of
ours, so the throw ended the run with exit code 91 and a reported FAILED run
with zero items. Every store open now goes through a wrapper that returns a
no-op store instead of throwing, so the free-run counter and the run SUMMARY
degrade and the actual work proceeds./v2/key-value-stores; it used a fixed limit=50, which silently
stopped containing gate stores once the account passed 50 of them — and the
account creates a new default store on every run, so that list grows on its
own. The lookup now pages (100 per page, up to 20 pages).defaultRunInput to .actor/actor.json (Layer 3 of §226).DEFAULT_URL) instead of running with the defaultRunInput the schema advertises.defaultRunInput mirrors schema defaults 1:1 (url, engine, commentId, raw), so empty-input runs now execute the schema-declared defaults.Actor.setValue does not just fail
under LIMITED_PERMISSIONS — it can simply never resolve. Measured on a live
run of a sibling Actor: results were fetched successfully, then the following
setValue never returned and the run sat for 49 minutes before being aborted
with an empty dataset and a $0.08 bill, and not one error in the log.
try/catch cannot help with that — it catches a rejection, not a promise that
never settles. SUMMARY and the other bookkeeping writes now race a15s timeout
and report the failure, so a stuck store costs one summary field instead of
the whole run.The daily free-run counter could take the whole run down. The gate had no
try/catch at all: checkAndIncrementFreeRuns called openGateStore(),
getValue() and setValue() in the open, so any failure propagated straight
out and killed the run. Apify's automated QA executes under
LIMITED_PERMISSIONS, where the named-store REST create is rejected — so this
fired on QA runs.
The whole open→get→set sequence now sits in one try. On failure the gate
reports through log.error + log.warning and returns
{allowed:true, degraded:true, degradedReason}, so the run continues
uncapped for that run. A genuinely exceeded cap still returns allowed:false
and remains a hard stop — that is the one case where failing closed is right.
A successful fetch could end with an empty dataset and no error. pushData
and setValue('SUMMARY', ...) fail silently under LIMITED_PERMISSIONS —
the SDK swallows the permission error, the run still reports SUCCEEDED, and
the caller cannot tell "found nothing" from "found something I could not
store". Confirmed on a live run: content was fetched (title and length in the
log) while the dataset held 0 items and SUMMARY was absent entirely. Both
writes are now wrapped, and a blocked dataset write sets an explicit status
message instead of passing for success.
freeTierCapDegraded / freeTierCapDegradedReason.
Without it a run that sailed past the cap is indistinguishable from one that
was properly counted, after the fact.checkAndIncrementFreeRuns and FREE_DAILY_RUN_LIMIT are now exported, so
the cap can be asserted on directly rather than inferred.test/gate-degradation.js, wired into npm test. It asserts both
directions: a broken store must fail open, and a healthy store must still
return allowed:false once the cap is reached — a gate that fails open
unconditionally would also pass a degrade-only test while never counting
anything again.