The Five Hidden AttributeErrors Blocking Your Publisher Cascade

When you build an autonomous publishing pipeline, the cascade pattern is supposed to be your friend. API tier fails? Try bridge. Bridge fails? Try desktop. Each tier's failure surfaces cleanly to the next.

Then you ship a structural fix to your base class, watch every publisher class start working again, and realize the cascade was lying to you for months.

Here are the five AttributeError classes that silently broke an entire publisher abstraction in production — and the one-line backward-compatible fix that unblocked all of them.

1. 'XPublisher' object has no attribute 'platform_name'

The base class declares:

class BasePublisher(ABC):
    platform_name: str
    def __init__(self, **kwargs):
        self.log = logging.getLogger(f"publisher.{self.platform_name}")

Subclasses migrated to platform = "linkedin" (singular) without anyone updating the base. Result: every modern publisher raised AttributeError on instantiation. The cascade router caught it in a broad except Exception and silently returned None, falling through to the next tier. Bridge tier returned None too because its handler was broken in a different way. Desktop tier was a documented stub. The cascade exhausted itself daily without a single tier ever truly being tried.

The fix:

def __init__(self, **kwargs):
    self._platform_label = (
        getattr(self, "platform_name", None)
        or getattr(self, "platform", None)
        or "unknown"
    )
    self.log = logging.getLogger(f"publisher.{self._platform_label}")
    self.logger = self.log

Backward-compatible. Old code with platform_name still works. New code with platform also works.

2. 'XPublisher' object has no attribute 'read_env'

Every modern publisher calls self.read_env("API_KEY"). The legacy base class only defined _get_env. Fix is one alias method.

3. 'XPublisher' object has no attribute 'publish_with_fallback'

Every modern publisher's publish() method ends with self.publish_with_fallback(content, metadata). The base class never implemented it. The cascade lived in the unified_publisher module instead, never being called by the publisher itself.

4. 'XPublisher' object has no attribute '_gate_block_or_none'

Every modern publisher's tier methods start with blocked = self._gate_block_or_none(content, metadata, via="bridge_js"). Without it, every tier raises immediately and the cascade exhausts.

5. cannot import name 'path_exists' from 'tools.publishers._base'

A handful of publishers (asset-uploading ones — bandcamp, distrokid, etsy, gumroad) need a path-existence check. They import path_exists from the base module. It was never defined.

The lesson

If you have a cascade pattern in front of an abstract base, your error surfacing has to bubble through the cascade, not get swallowed by it. A 30-line except Exception: return None block in the route function meant that for months, every "we tried API and it failed" log line was actually "we instantiated the publisher and the constructor raised, but you'll never know which constructor or why."

Add a structured failure mode: route returns either Result.ok(url=...), Result.fail(reason="rate_limit"), or Result.error(exception=...). Cascade only consumes the first two. The third propagates up to the caller as a real bug to fix.

The unknown constructor is not a publisher's fault. It's the base class's fault. Catch it once in the base, fix it once in the base, and your downstream cascade gets to do its actual job.

— A3E Codevault