ZacharyZhang-NY
e74dafcd36
Three independently ugly bugs that all fed the same log flood:
* Electron's `WebFrameMain.send` writes every "Render frame was disposed"
to stderr via `console.error`. When the worker fans a second
agent-event past a reloading renderer, we produced thousands of
identical lines and stalled the main loop on stderr I/O. Added a
`mainFrame.detached` guard so the send is short-circuited before
Electron's own catch block fires, and installed a targeted filter in
`suppress-warnings.ts` (now actually imported from the entry point)
so the specific `console.error("Error sending from webFrameMain:"…)`
noise never reaches the terminal. Any other payload still surfaces.
* `dispatchAgentMessage` accepted the human-reader sentinel as a wake
target when an agent replied to `__board__` — `wakeAgentIfPossible`
then called `db.getAgent("__board__")`, threw, and the dispatcher
kept repeating on every send. Strip `HUMAN_SENDER_ID` at
`resolveMessageWakeTargets`, and keep a defense-in-depth guard in the
heartbeat so a stray caller (future automation fan-out) cannot
reintroduce the crash.
* Pi's skills loader rejects any SKILL.md whose frontmatter `name`
diverges from its parent directory. The four bundled `my-writing-style`
copies declared `name: writing-style-skill`, so every install emitted
a warning and dropped the skill. They also lived as orphan gitlinks
(mode 160000 without .gitmodules), and the global `*.md` gitignore
hid every other SKILL.md from version control. Fixed the frontmatter
to match the dir, converted the dangling submodules to plain trees,
and allowlisted `builtin-skills/**/*.md` so a fresh clone carries the
catalogue instead of silently losing it.
3.2 KiB
3.2 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Declare All Dependencies Explicitly in Constructor | HIGH | enables testing, documents requirements, prevents hidden coupling | usecase, dependencies, constructor, injection |
Declare All Dependencies Explicitly in Constructor
Use cases should receive all dependencies through their constructor. Hidden dependencies (service locators, singletons, static calls) make testing difficult and hide coupling.
Incorrect (hidden dependencies):
public class PlaceOrderUseCase {
public OrderConfirmation execute(PlaceOrderCommand command) {
// Hidden dependencies - impossible to test or trace
var customer = CustomerRepository.getInstance().find(command.customerId());
var inventory = InventoryService.getInventory();
for (var item : command.items()) {
if (!inventory.isAvailable(item)) {
throw new OutOfStockException(item);
}
}
var order = new Order(customer, command.items());
// More hidden dependencies
Database.getConnection().save(order);
EmailService.send(customer.email(), "Order placed");
EventBus.publish(new OrderPlacedEvent(order));
return new OrderConfirmation(order.id());
}
}
// Testing requires mocking static methods - complex and brittle
Correct (explicit constructor dependencies):
public class PlaceOrderUseCase {
private final CustomerRepository customers;
private final InventoryChecker inventory;
private final OrderRepository orders;
private final NotificationPort notifications;
private final EventPublisher events;
public PlaceOrderUseCase(
CustomerRepository customers,
InventoryChecker inventory,
OrderRepository orders,
NotificationPort notifications,
EventPublisher events
) {
this.customers = customers;
this.inventory = inventory;
this.orders = orders;
this.notifications = notifications;
this.events = events;
}
public OrderConfirmation execute(PlaceOrderCommand command) {
var customer = customers.find(command.customerId());
for (var item : command.items()) {
if (!inventory.isAvailable(item)) {
throw new OutOfStockException(item);
}
}
var order = new Order(customer, command.items());
orders.save(order);
notifications.orderPlaced(customer, order);
events.publish(new OrderPlacedEvent(order));
return new OrderConfirmation(order.id());
}
}
// Testing is straightforward
@Test
void placesOrderWhenInventoryAvailable() {
var customers = mock(CustomerRepository.class);
var inventory = mock(InventoryChecker.class);
var orders = mock(OrderRepository.class);
// ... configure mocks
var useCase = new PlaceOrderUseCase(customers, inventory, orders, ...);
var result = useCase.execute(command);
verify(orders).save(any(Order.class));
}
Benefits:
- Dependencies visible in constructor signature
- Tests substitute any dependency with test doubles
- Coupling is explicit and measurable
Reference: Dependency Injection Principles