Q: 동일한 flow의 두 실행이 겹칠 때 flow dedup가 항목을 이미 본 것으로 잘못 표시하는 이유는 무엇인가요?

이 문제는 레이스 컨디션이었습니다: dedup 노드가 공유된 `dedup: :tentative` 세트에 기록했기 때문에, 성공한 실행이 아직 실행 중이거나 (또는 실패한) 겹치는 실행의 tentative 키를 커밋할 수 있었고, 정산(settlement)은 실행이 시작된 시점의 그래프 대신 현재 저장된 플로우 정의를 사용했습니다. 수정 사항은 TinyFlows v0.8.29 (tinyhumansai/tinyflows#165)에서 배포되었으며, tentative 키를 실행 단위로 스코핑하고(`dedup: :tentative: `) 실행에 대해 영속화된 그래프 스냅샷을 기준으로 정산합니다. PR #8170을 포함하는 빌드로 OpenHuman을 업그레이드하세요 (해당 PR은 TinyFlows를 v0.8.29+로 올립니다). 이전 버전에서의 우회 방법: 공유 tentative 세트는 동시 실행 간에만 충돌하므로, 동일한 플로우의 중복/동시 실행을 피하세요.

Question 1

왜 504 gateway timeout 이후 task-state compaction이 대화 기록을 아무 경고 없이 유실하며, 이를 어떻게 해결할 수 있나요?

Accepted Answer

컴팩션 시도 루프는 마크업/JSON 파싱 실패만 재시도했기 때문에, 관리형 게이트웨이에서 재시도 가능한 504가 발생하면 첫 시도에서 청크가 삭제되고 이전 상태가 유지되면서도 여전히 `degraded=false`로 보고되었습니다(`chunks_skipped=2 degraded=false`). 이후 긴 스레드에서는 대부분의 히스토리가 결정적 원장으로만 남게 됩니다. 해결 방법: 재시도 가능한 전송 오류(5xx/타임아웃)를 시도 루프 내부에서 재시도하고 건너뛴 청크를 모두 degraded로 보고하며 회귀 테스트도 포함하는 tinyagents PR #427(벤더링된 tinyagents를 통해 main에 머지됨)이 포함된 빌드로 업데이트하세요. 업그레이드 전까지의 임시 해결 방법: 단일 호출이 ~60초 게이트웨이 타임아웃 내에 완료되도록 `agent/tinyagents/harness_context_ladder.rs`에서 관리형 경로 청크 상한을 최대 100k에서 ~40–50k 토큰으로 낮추세요(`(window*2/5).clamp(4_000, 100_000)` 설정).

Question 2

OpenHuman 워크플로우가 "Completed"로 표시되는데 출력이 나타나지 않는 이유는 무엇인가요?

Accepted Answer

근본 원인 (수정됨): 코드 노드가 존재하지 않는 `item` 변수를 참조했습니다 — 런타임은 실제로 페이로드가 `.json` 아래에 있는 항목들의 배열인 `input`을 전달합니다 — 또한 dry run이 코드 노드를 스텁으로 대체했기 때문에 충돌이 발생한 스크립트가 정상으로 잘못 보고되었습니다.

수정 방법:
1. TinyFlows v0.8.29+가 포함된 OpenHuman 빌드로 업데이트하세요 (tinyflows#166, tinyagents#503, OpenHuman #8170/#8179를 통해 통합됨). 이제 dry run은 실행되지 않은 코드 노드와 바인딩되지 않은 `item` 읽기를 표시하고, 실패한 에이전트 실행은 실제 오류를 로그에 기록합니다.
2. 기존 워크플로우에서는 코드 노드를 `item` 대신 `input`을 사용하도록 다시 작성하세요 — 예를 들어 `input[0].json`을 통해 페이로드에 접근합니다.

진단 방법: 실행 세부 정보를 열고 각 단계의 출력을 펼치세요. 출력이 비어 있거나 `null`로 표시되는 단계가 아무 표시 없이 실패한 단계입니다. 최신 빌드에서도 문제가 지속되면 해당 실행의 단계 출력을 첨부하여 새 이슈를 여세요.

Question 3

credential_scrub가 도구 출력에서 'accessToken: string'이나 'action.payload' 같은 일반 소스 코드를 왜 마스킹 처리하나요?

Accepted Answer

이는 tinyinference의 sanitize.rs에 존재하는 알려진 과도한 마스킹(over-redaction) 리그레션으로(commit a5f129d, PR #60에서 도입됨), `looks_like_secret`이 키와 일치하는 경우에만 단독 식별자를 마스킹에서 제외했고, 타입 어노테이션 예외는 대문자로 시작하는 타입에만 적용되어 TS `string`은 포함하지 않았으며, `SENSITIVE_KV_REGEX`가 `action.payload`와 같은 점 구분 경로를 통째로 캡처하는 문제입니다. 이는 tinyinference PR #95에서 수정되었습니다: tinyinference main(또는 빌드에 vendored된 tinyinference)으로 업데이트하면 타입 어노테이션(`accessToken: string`)과 점 구분 멤버 경로는 마스킹되지 않고 그대로 통과하는 반면, 실제 시크릿(예: `password=correcthorse`, 실제 토큰)은 계속 마스킹된 상태로 유지됩니다. 참고: `*_KEY` 아래의 짧은 따옴표로 묶인 값은 설계상 계속 마스킹됩니다.

Question 4

백그라운드 작업의 승인 요청이 항상 타임아웃되어 거부되는 이유는 무엇인가요?

Accepted Answer

백그라운드 작업(원격 채널 트리거, 워크플로 자동화, 목표 이어가기)은 대화형 세션이 연결되지 않은 상태에서 승인 요청을 발생시키므로, 기존에는 이를 결정할 수 있는 주체가 없어 항상 TTL-deny로 만료되었습니다. 이 문제는 #6491에서 수정되었습니다. 이제 백그라운드 작업에서 보류된 승인 요청이 `/chat` 페이지에 조치 가능한 승인 배너로 표시되어 사후에 승인하거나 거부할 수 있으며, 모든 결정은 `approval_decide`를 통해 감사 추적에 기록됩니다. 이러한 출처(ExternalChannel, TrustedAutomation, `require_approval:true`가 설정된 Workflow)는 fail-closed 보안 태세의 일환으로 자동 허용 대신 의도적으로 보류된다는 점에 유의하세요. 이는 의도된 동작입니다. 알려진 제한 사항: 앱이 닫혀 있는 동안 보류된 요청은 600초 TTL이 만료되면 여전히 거부됩니다. 대기 중인 승인을 놓치지 않으려면 앱을 열어 두고, TTL-deny 처리된 요청의 감사 기록은 `pending_approvals` 테이블에서 확인하세요.

Question 5

동일한 flow의 두 실행이 겹칠 때 flow dedup가 항목을 이미 본 것으로 잘못 표시하는 이유는 무엇인가요?

Accepted Answer

이 문제는 레이스 컨디션이었습니다: dedup 노드가 공유된 `dedup::tentative` 세트에 기록했기 때문에, 성공한 실행이 아직 실행 중이거나 (또는 실패한) 겹치는 실행의 tentative 키를 커밋할 수 있었고, 정산(settlement)은 실행이 시작된 시점의 그래프 대신 현재 저장된 플로우 정의를 사용했습니다. 수정 사항은 TinyFlows v0.8.29 (tinyhumansai/tinyflows#165)에서 배포되었으며, tentative 키를 실행 단위로 스코핑하고(`dedup::tentative:`) 실행에 대해 영속화된 그래프 스냅샷을 기준으로 정산합니다. PR #8170을 포함하는 빌드로 OpenHuman을 업그레이드하세요 (해당 PR은 TinyFlows를 v0.8.29+로 올립니다). 이전 버전에서의 우회 방법: 공유 tentative 세트는 동시 실행 간에만 충돌하므로, 동일한 플로우의 중복/동시 실행을 피하세요.

OpenHuman

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트