sync: upstream moxygen d600e7d29660 - #384
Merged
Merged
Conversation
Summary: `MoQClientBase` already knows what a session ended up running over -- it holds the QUIC socket, the `QuicWtSession`, and `negotiatedProtocol_` -- but all three are protected, so a client can only report the transport its *config* asked for. Those differ: the config is a request, and what the connect settles on is a result. This adds three `[[nodiscard]]` accessors alongside the existing `getTransportConnectTime()` and `getMoQHandshakeTime()`: | Accessor | Reports | | --- | --- | | `hasQuicTransport()` | whether a QUIC transport is established -- false before connect completes, and for non-QUIC transports such as QMUX | | `usesQuicWtSession()` | whether the session runs over a `QuicWtSession` rather than the older `QuicWebTransport` path | | `getNegotiatedProtocol()` | the negotiated ALPN, empty until the transport negotiates one | TigonMoQ uses them to classify the established transport and to annotate its session-establishment telemetry with both the requested and the negotiated ALPN, so a negotiation that comes back empty -- or returns something outside the requested set -- is visible rather than silent. Additive and inline: no behaviour change, no existing caller affected. Note that `MoQClientBase.h` exists in both `fbcode/` and `xplat/` and the two are kept byte-identical, so both copies carry the change. The build uses the `fbcode/` copy. ___ Differential Revision: D116791417 fbshipit-source-id: 1547bb6c76896cdb9f7de41447d3bb345182d244
Summary: Remove standalone `# pyre-strict` and `# pyre-unsafe` mode headers from Python files under `fbcode/ti`. Pyrefly type-checks all files in one consistent mode, so these legacy per-file mode headers no longer have an effect. Other Pyre directives and generated files are left unchanged.Pyrefly is now the default type checker across FBCode so this diff introduces no functional changes. #pyreupgrade Differential Revision: D117227662 fbshipit-source-id: 775efbba8038ee6238603b16d57d33851a5f8466
Summary: Wires BGP++ to the `FBOSS_BUILD_PROFILE=fsdb_client` gate so building BGP++ no longer compiles the FBOSS agent, SAI, qsfp, platform, led, cli and test trees. BGP++ links ~90 FBOSS static archives, all of them in FBOSS's `install(TARGETS ...)` export list, but getdeps builds every dependency with the CMake `install` target and `install` depends on `all`. So BGP++ has been paying for the entire FBOSS build: 4353 ninja edges against its own 285. Uses the existing getdeps feature mechanism rather than a second manifest or a separate FSDB repo. Same source tree, same manifest, same install dir - only the target set changes, and it reverts by flipping one default. `manifests/fboss` declares a `services` feature, on by default: ```ini [features] default = services services = [cmake.defines.feature_services=off] FBOSS_BUILD_PROFILE=fsdb_client ``` `manifests/bgp` opts out: ```ini fboss = !default, !services ``` The explicit `!services` prohibition alongside `!default` is deliberate. `parse_dep_spec` records `!default` as `opt_out_default` and never adds it to the prohibited set, so a bare `!default` would let a future manifest that consumes both `fboss` and `bgp` contribute the default back and silently give BGP++ a full FBOSS. The prohibition turns that into a hard error instead. Polarity is opt-out rather than opt-in for the same reason. With opt-in, a consumer of both projects would union to the reduced set and silently receive a *lite* FBOSS - failing toward missing targets. Opt-out fails toward building too much, and the genuinely dangerous case is loud. Reviewed By: KevinYakar Differential Revision: D116334077 fbshipit-source-id: 50b55a23f9954d8942d95774c38f32a269353282
Summary:
Move of the experimental EdenFS daemon tree from `fbcode/eden/fs2` to `fbcode/eden/fs/facebook/experimental` via `sl mv` (367 files, history preserved). No targets, crates, or identifiers are renamed in this commit — that follows in the rest of the stack.
Path references updated alongside the move:
1. Buck target/package paths embedded in the dod tooling (`tools/lib/env.rs`, `tools/lib/correctness.rs`, `tools/lib/thrift_gate.rs`) and `macos/build-ffi.sh`.
2. `fbcode/eden/fs2` paths in docs (`blueprint.md`, `dod-*.md`, `docs/architecture/README.md`, `third-party/pjdfstest/README.meta`).
3. `tools/arcanist/lint/fbsource-licenselint-config.toml`: the `!fbcode/eden/fs2/**` exclusion is dropped — the new location is already covered by `!fbcode/eden/**/{facebook,fb}/**`.
4. `fbcode/opensource/fbcode_builder/manifests/{eden,sapling}`: the `^fbcode/eden/fs2/.*$` shipit strip rule is rewritten to `^fbcode/eden/fs/facebook/experimental/.*$`, preserving the exact strip semantics in both `fb=on` and `fb=off` contexts (the `^.*/facebook/.*$` rule only applies under `fb=off`).
Build-configuration fixes the move makes necessary: the new location is inside the `scm_client_infra` citadel sanity-check scope, so the package is now built under `fbcode//mode/opt-win` and `fbcode//mode/opt-mac-arm64` — two configurations `fbcode/eden/fs2` was never exercised in.
1. Windows. The daemon, the library and the dod tooling are Unix-only by construction: `std::os::unix`, `std::os::fd`, `rustix::fs`, `rustix::process`, `signal_hook::iterator` and `tokio::net::UnixStream` have no Windows equivalents here. Every target now carries `compatible_with = LINUX_AND_MACOS`, except `fuse_abi` and `eden2d`, which stay `LINUX_ONLY` as before. Under `mode/opt-win` all 110 configured targets in the package are skipped as incompatible instead of failing to compile.
2. macOS. `lru` moves from the `ovr_config//os:linux` branch of `eden2-lib`'s `select` into the common `deps`: its users, `src/backing/sapling.rs` and `src/fs/fnfs.rs`, are OS-common, so the macOS build failed with `error[E0433]: cannot find module or crate lru`. Symmetrically, `sha1` moves into the Linux branch — its sole user is the Linux-gated `src/thrift/handler.rs`, so macOS flagged it as an unused dependency.
Reviewed By: genevievehelsel
Differential Revision: D117018989
fbshipit-source-id: 93a3d074cc9b7f340e57f21cf43ed61e30bf39c9
gmarzot
approved these changes
Aug 25, 2026
gmarzot
left a comment
gmarzot
left a comment
Collaborator
There was a problem hiding this comment.
Auto-approved by upstream sync workflow.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automated upstream sync.
d600e7d29660The verify workflow will validate the standalone build. On success, this PR auto-merges.
Devs can push conflict-resolution commits to
sync/d600e7d29660if needed.Created by
omoq-upstream-syncworkflow.This change is