대상: flatpak/xdg-desktop-portal
이슈: flatpak/xdg-desktop-portal#1947
풀 리퀘스트 (Pull request): flatpak/xdg-desktop-portal#2054
현장 연구소 (Field Lab) 기록: xdg-desktop-portal #1947
이 현장 테스트는 누락된 백그라운드 앱에 관한 것이었으나, 실제 경계는 "백그라운드 앱은 신뢰할 수 없다"가 아니었습니다.
그것은 너무 모호할 것입니다.
공개된 이슈는 xdg-desktop-portal이 시작되기 전에 이미 실행 중인 백그라운드 애플리케이션이 나중에 어떤 창이나 앱 상태 변화가 업데이트를 트리거할 때까지 BackgroundApps에 나열되지 않는다는 점을 보고했습니다.
실패하는 경로는 좁았습니다.
포털은 향후의 변경 사항을 감시(listen)했습니다.
시작될 때 이미 실행 중인 항목은 확인하지 않았습니다.
이것이 버그의 형태입니다.
고장 난 공개 API가 아닙니다.
광범위한 Flatpak 백그라운드 앱 실패도 아닙니다.
시작 인벤토리 패스 (startup inventory pass)의 누락입니다.

현장 연구소 (Field Lab) 기록

이 케이스에 대한 공개 현장 연구소 기록은 여기에 있습니다:
ADD FIELD LAB LINK HERE
기록에는 공개 이슈, 공개 풀 리퀘스트 (pull request), 수정 범위, 검증 요약 및 클레임 경계가 포함되어 있습니다.
이 포스트는 읽기 쉬운 현장 보고서입니다.
현장 연구소 기록은 증거 계층입니다.

SDS 결과

SDS는 백그라운드 포털에서 시작 인벤토리 경계를 드러냈습니다.
중요한 발견은 작았습니다:
백그라운드 포털이 시작 중에 이미 실행 중인 백그라운드 앱을 확인해야 한다는 것이었습니다.
기존의 모니터링 경로가 이미 이후의 변경 사항을 처리하고 있었기 때문에 이것은 중요합니다.
버그는 첫 번째 변경 이벤트 이전의 공백이었습니다.
백그라운드 앱이 이미 존재할 수 있습니다.
포털이 이미 실행 중일 수 있습니다.
하지만 모니터가 새로고침되도록 하는 나중의 신호가 발생할 때까지 BackgroundApps는 여전히 빈 상태로 시작될 수 있습니다.
이것은 전형적인 시작 상태 (startup-state) 버그입니다.
시스템은 나중에 올바르게 될 능력이 있습니다.
단지 처음에 잘못 시작될 뿐입니다.

수정 전

수정 전에는 백그라운드 앱 상태가 향후 모니터 트리거 이벤트를 통해 결정되었습니다.
포털은 시작 전에 이미 실행 중이던 앱을 놓칠 수 있었습니다.
첫 번째 SDS 가이드 패치는 명백하고 좁은 수정을 사용했습니다:

c
monitor_background (background);
...