apache/iggy

Bug description Bug description iggy-server panics immediately at startup on Intel macOS (x86_64) and never binds a listener. The build succeeds; the failure is at runtime. The guard in core/server_common/src/executor.rs:87 applies thread_pool_limit(0)` on every target except macOS aarch64 #[cfg(not(all(target_os = "macos", target_arch = "aarch64")))] proactor.thread_pool_limit(0); On macOS x86_64 the condition is therefore true and the zero limit is applied. compio's polling driver (used on macOS, since there is no io_uring) routes fs operations through the blocking pool, so the first fs operation panics. The comment directly above that line describes the exclusion as applying to macOS generally, with no architecture qualifier Expected: server starts on Intel macOS. Actual: panics before binding any listener. Why CI did not catch it The only macOS Rust job is build-macos-aarch64 on macos-14 (.github/workflows/_test.yml:44). macos-15-intel appears only in _build_python_wheels.yml. Inte

Description sdk-python declares tasks: ["lint", "test", "build"], and each task becomes its own job on its own runner. The build task compiles the wheel and throws it away: its dist/ never reaches Upload test artifacts, which only runs under test. So the crate is compiled twice per push and nothing is shared between the jobs. At the same time apache_iggy.pyi has no freshness gate. The file header says it is generated by pyo3_stub_gen, the README says "nothing in CI checks stub freshness", and the stub has already drifted from the source: describe_options sits in a different position with its return type written as builtins.list[OptionSpec], and two docstrings were edited by hand. Checking this needs a built crate, so today there is nowhere cheap to put the check. Affected area / component CI / build / tooling Proposed solution Drop the build task and move maturin build -o dist into test: tasks: ["lint", "test"] lint = ruff + cargo fmt + clippy + pyrefly, unchanged test = wheel + stub

Description Summary Implement an Iggy Source/Sink Connector that consumes data from an upstream Iggy cluster and publishes it into a downstream Iggy cluster. This enables seamless cluster-to-cluster replication and provides the foundation for multi-region deployments, disaster recovery, active-active architectures, edge-to-cloud streaming, and hierarchical streaming topologies. Unlike traditional application-level replication, this connector allows operators to replicate selected streams, partitions, or namespaces without requiring producers or consumers to change. Motivation Many production deployments require data to exist in multiple locations. Today, applications would need to publish to multiple Iggy clusters directly, increasing complexity and coupling replication logic into business applications. A native Iggy Source/Sink Connector would make replication a first-class capability by continuously consuming from one cluster and publishing to another while preserving ordering and de

Description Add an Apache Airflow connector so Iggy can drive event-driven DAGs via the Airflow REST API. This is tracked on the connector ecosystem roadmap (#2753) under Workflow & Orchestration: Target Type Priority Comp Suggested stack Apache Airflow Trigger P4 1/4 reqwest (REST API) Roadmap intent: Iggy sensor/trigger for event-driven DAGs. There is no Airflow sink/source (or trigger plugin) in-tree today, no dedicated implementation issue before this one, and no open PR claiming the work. Motivation Airflow is the industry-standard workflow orchestrator; pairing it with Iggy enables stream-driven DAG triggers instead of polling-only sensors. Existing connectors cover DBs, search, lakehouse, and HTTP egress, but nothing in the workflow/orchestration category is implemented yet (Airflow, Temporal, Prefect, Dagster are all still roadmap-only). A first cut can likely reuse patterns from http_sink (auth, retries, batching) while specializing for Airflow's trigger/DAG-run API

Description Type: ci / security Labels: security, ci, dependencies, A-tooling Source: discussion #3678 Summary Wire cargo deny into the pre-merge CI pipeline (.github/actions/rust/pre-merge) so every PR is gated on advisory scanning, license policy, banned crates, and duplicate-version detection across the full dependency graph. Mirror the check in the local pre-commit config so contributors catch failures before pushing. Motivation cargo audit only covers known vulnerabilities. cargo deny is a superset gate: in addition to RustSec advisories it enforces open-source license policy, bans specific crates, and flags duplicate dependency versions. A pre-merge gate prevents new advisories and policy violations from re-entering the tree after the one-time remediation (sibling audit issue) lands. Reference: https://github.com/EmbarkStudios/cargo-deny Affected area / component Other / not sure Proposed solution Proposed approach Add a committed deny.toml at repo root with sections: [advisori