Skip to content

DisciplineServer inherits the experimental static-API class instead of the servicer #70

Description

@chrislupp

philote_mdo/general/discipline_server.py:41 declares:

class DisciplineServer(disc.DisciplineService):

DisciplineService (generated stub, philote_mdo/generated/disciplines_pb2_grpc.py:109) is the experimental static API — a collection of @staticmethods wrapping grpc.experimental.unary_unary(...), intended for one-shot calls against a target address without constructing a channel. It is not a servicer base class.

The correct base is DisciplineServiceServicer (disciplines_pb2_grpc.py:39), which is what add_DisciplineServiceServicer_to_server is designed to accept.

Why it currently works

Two things mask it:

  1. add_DisciplineServiceServicer_to_server duck-types the handler lookup — it does getattr(servicer, "GetInfo") etc. rather than checking the type.
  2. DisciplineServer overrides all eight RPC methods itself, so no inherited staticmethod is ever reached.

Note that ExplicitServer and ImplicitServer do mix in the correct ExplicitServiceServicer / ImplicitServiceServicer, so the inconsistency is confined to the base class.

Why it should still be fixed

It is latent rather than active, but it is misleading to read, and it means DisciplineServer does not inherit the UNIMPLEMENTED defaults that a servicer base is supposed to provide — so a subclass that forgets to implement an RPC gets an AttributeError at registration time instead of a clean UNIMPLEMENTED status at call time.

Fix

Change the base to disc.DisciplineServiceServicer and confirm nothing depends on the current MRO. Should be a one-word change plus a test run.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions