Good First Issues in Go

Is this related to a problem? Please describe. #1272 added a configurable startup warmup (--readiness-warmup-ms / STARGATE_READINESS_WARMUP_MS, default 60000) that keeps /readyz unavailable for a fixed window so Pylons have time to register and establish reverse tunnels before a new Stargate replica receives API gateway traffic. That fixed window is a worst-case bound — it always waits out the full duration even when Pylon registration finishes and stabilizes within a few seconds, which unnecessarily slows scale-up and rolling restarts in the common case. Describe the solution you'd like Let the warmup complete early, once it's clear the replica is already healthy, instead of always waiting out the fixed timer: Sample StargateState's total active backend count once per second (sample interval configurable). Once that count is greater than zero and has stayed unchanged for N consecutive samples (default 5 seconds), treat the replica as ready immediately rather than waiting for the re

#4223 introduces a cache that is caching parsed filters and predicates for a single RouteGroup. Sometimes you have a lot of RouteGroups that look very similar with a lot of predicates and filters that we could cache. Think about Method("GET") you have almost N times in every RouteGroup. It does not need to be parsed on every RouteGroup again.

功能描述 希望能加入自动制造设备的功能，自动使用指定原料制造任意没有堆满仓库（版本上限，目前是9万）的设备 溢出的产物做成设备，再也不用担心爆仓了，顺便做个全物品满仓（可以的话，希望把谷地也加上） 这是目前所有“建材”产能和设备需求的统计，因为“建材”的仓储空间太小，很容易爆仓，如果全部矿物做成设备，1小时就得制作一次，手动操作会非常磨人，只能拜托MAA啦。目前的灼铜零件产能最高14.4/min（部分铜矿做重息壤），单是做满9万个暴雨铳械塔就需要87天（每天建材满仓一次，设备制作一次） 日志文件 MaaEnd-logs-v2.25.0-20260828-213159-part01.zip MaaEnd 版本 v2.25.0 其他信息 产物用不完，与其爆仓，不如做成设备

问题 当前 SubTask 使用 ctx.RunTask 执行子任务，存在以下问题： 日志层级丢失 子任务通过 RunTask 单独运行，后续节点都会被归到对应的子任务下，日志分析时难以还原原本的任务流程。 嵌套问题 SubTask 可能在 Go 内部嵌套执行其他 Custom Action 或 Recognition，导致任务层级不断加深，增加崩溃风险和维护成本。 优化方向 考虑将 SubTask 从 ctx.RunTask 改为基于 OverrideNext + [JumpBack] 的链式调度： 不再在 Go 内部嵌套运行子任务 保持任务节点在原有 Pipeline 层级中执行 改善日志中的任务层级 使用 attach 保存原始 next 和执行状态 子任务执行完成后恢复原本的 next 目前不确定 continue 和 strict 应如何处理： 因为按照当前的思路来说,SubTask只是作为调度器使用了,任务具体运行交给了pipeline,出现错误时,SubTask是无法得知的

Summary IncusOS has no way to issue TRIM/discard to the SSDs backing its ZFS pools, and no way for an operator to arrange one. scrub_schedule has no trim counterpart, and the design (correctly) leaves no shell to run zpool trim from. I'd like to propose a trim_schedule field alongside scrub_schedule, and optionally a trim-pool action mirroring scrub-pool. Why there is currently no path As far as I can tell from the source, nothing in the stack ever trims: CreateZpool passes ashift=12, mountpoint=none and the encryption options — no autotrim. Incus itself sets autotrim=on, but only in its pool creation path. A pool created by incus-osd and then adopted by Incus via source= never goes through that path, which is the normal IncusOS arrangement. SystemStorageConfig exposes pools, scrub_schedule and allow_mixed_dev_sizes; pools expose name, type, devices, cache/log/special. There is no field for autotrim or any other zpool property. The storage actions are scrub-pool, delete-pool, wipe-d

Summary Software backend's SPIR-V interpreter silently returns zero for ~36 unimplemented GLSL.std.450 opcodes. No warning — silent data corruption on any platform using the software backend (servers, embedded, CI, containers, any device without GPU). Current state hal/software/shader/glsl_ext.go implements 47 of ~83 GLSL.std.450 opcodes. The default case at line 345 returns ValUint(0) without any diagnostic. A shader using determinant() in CI silently gets 0.0. Short-term fix Add slog.Warn to the default return — stop hiding the problem: default: hal.Logger().Warn("unimplemented GLSL.std.450 opcode", "opcode", op) return ValUint(0) Architecture: Interpreter + Go Native SIMD are complementary The SPIR-V interpreter (~14K LOC) and the planned naga Go Native SIMD backend serve different roles: SPIR-V Interpreter naga Go Native SIMD Input Any SPIR-V binary naga IR (compile-time) When Runtime (dynamic shaders) Build-time (pre-compiled) Debugging Breakpoints, JSON tr

Summary Expand WebGPU validation coverage from ~45% to ~70% of Rust wgpu-core checks. Currently 55 validation functions across core/validate.go (26), internal/raytracing/validate.go (17), and core/indirect_validation.go (12). Key gaps: feature gates, texture usage conflicts, render pass compatibility. Priority areas Feature gate checks (highest impact) None of the 25 feature flags are validated at usage time: FeatureTimestampQuery — not checked on CreateQuerySet FeatureMultiDrawIndirect — not checked on multi-draw calls FeaturePushConstants — not checked on PipelineLayout with push constants FeatureShaderF16 — not checked on shader module with f16 FeatureRayQuery — checked in internal/raytracing/ (9 checks), but NOT in core/ Texture usage conflicts Complete conflict matrix (CopySrc+CopyDst mutual exclusion in same pass) Storage texture read-write conflict detection Multisampled texture usage restrictions Render pass compatibility Color attachment format mismatch with pip

Summary Windows GLES has a mutex-protected AdapterContext (167 LOC) with Lock()/Unlock() + runtime.LockOSThread() for thread-safe GL context switching. Linux GLES lacks this abstraction — context management is split between Instance and Surface with no formal locking. Current state Windows (hal/gles/adapter_context.go): Single WGL context owned by Instance Lock() / LockForDC() / Unlock() with mutex + runtime.LockOSThread() Surface borrows context via Lock — lightweight Linux (hal/gles/api_linux.go): X11/headless: Instance creates EGL context, shares with Surface (ownsContext: false) Wayland: Surface creates own EGL context (ownsContext: true) — GL objects not shared across surfaces No mutex, no Lock/Unlock, no runtime.LockOSThread() What's needed adapter_context_linux.go with EGL Lock/Unlock pattern matching Windows Mutex + runtime.LockOSThread() for thread safety on Linux Wayland context-per-surface as documented intentional divergence Refactor api_linux.go Instance to use

Summary Pipeline cache reduces pipeline creation time on second launch by caching driver-compiled GPU ISA to disk. Currently we pass VK_NULL_HANDLE / null on both Vulkan and DX12 — all pipelines recompile from scratch every launch. Why this matters For 15-30 pipelines (typical GUI app): Scenario Cold start Current (no cache) ~150-300ms With pipeline cache ~3-5ms Pipeline cache is independent of shader compiler — DXIL, FXC, or SPIR-V all benefit. The cache saves driver-compiled GPU ISA (machine code), not shader bytecode. Vulkan VkPipelineCache API bindings fully generated in vk/commands_gen.go (lines 1497-1541): CreatePipelineCache, DestroyPipelineCache, GetPipelineCacheData, MergePipelineCaches. All loaded but unused — pipeline.go:324 passes 0 as cache handle. Rust wgpu has full Vulkan pipeline cache implementation (wgpu-hal/src/vulkan/device.rs:2448-2466). Work: Add pipelineCache field to Vulkan Device Create cache at device init, pass to all vkCreateGraphicsPipeli

Summary Device.CreateQuerySet and Device.CreateRenderBundleEncoder are fully implemented on all 6 HAL backends but have no public API wrapper. Users must access HAL directly to use these features. What's ready (all 6 backends) CreateQuerySet: Vulkan: hal/vulkan/query.go DX12: hal/dx12/query.go Metal: hal/metal/device.go GLES: hal/gles/device.go Software: hal/software/device.go (returns ErrTimestampsNotSupported) Noop: hal/noop/device.go (returns ErrTimestampsNotSupported) CreateRenderBundleEncoder: implemented on all 6 backends. What's missing Two methods in root package (device_native.go, ~30 LOC each): func (d *Device) CreateQuerySet(desc *QuerySetDescriptor) (*QuerySet, error) func (d *Device) CreateRenderBundleEncoder(desc *RenderBundleEncoderDescriptor) (*RenderBundleEncoder, error) Plus corresponding public types if not yet in the root package. Impact Without CreateQuerySet, users cannot do timestamp or occlusion queries through the public API. This is a gap for profiling and p

related to: #53273 Windows unit CI intermittently reports a concurrent access to the client-side http.Request.Header while sending a CloudWatch Logs request: fatal error: concurrent map read and map write net/http.Header.sortedKeyValues net/http.Header.writeSubset net/http.(*Request).write net/http.(*persistConn).writeLoop The failure was discovered through TestNewAWSLogsClientUserAgentHandler and is tracked as test flakiness in #53273. PR #53322 isolates that test from the real HTTP transport, but does not identify or fix the concurrent writer. Production awslogs requests use the same AWS SDK and Go HTTP transport path, so the underlying request ownership race should be tracked separately. Current findings The stack identifies net/http reading the header map, but does not include the writer stack. The httptest.Server cannot mutate this map because it receives a separately parsed server-side request. Moby and AWS middleware normally update headers before Smithy calls http.Request.C

问题描述及复现步骤 如标题所示以vulkan模式启动终末地后，全屏模式下在maaend开始任务maaend会不断打开手表又关上并且每个动作之间大量留白站桩，无法实际完成任务，概率点进邮箱看一眼并完成领取邮箱奖励的任务(但我邮箱没东西所以不知道是不是真能完成但的确看了)，小概率点到其他地方去(也有可能是我不小心移了鼠标之类的?)，修正如果在地上的话可能只会按左键，前面都是在帝江号上的时候测的，切换窗口模式或者以dx11模式启动终末地就不会有这种问题，我个人推测可能是vulkan问题，我的是老核显，vulkanapi版本是1.3.260(但理论来讲1.3也并不低?)，理论上来讲能点进游戏(点击开始游戏能做到，后面就是站桩)，应该是鼠标移动点击画面识别都没问题吧，到底为什么会卡住呢，日志可以看版本，最新正式版和测试版都测了 日志文件 测试版测

Descriptions As mentioned by our users, the available refresh interval list is limited to very low range numbers which may not be appropriate for some cases. Investigating the code based, it turned out that the corresponding control is fed by a list of limited Duration Strings plugin-system\src\components\TimeRangeControls\TimeRangeControls.tsx export const DEFAULT_REFRESH_INTERVAL_OPTIONS: TimeOption[] = [ { value: { pastDuration: '0s' }, display: 'Off' }, { value: { pastDuration: '5s' }, display: '5s' }, { value: { pastDuration: '10s' }, display: '10s' }, { value: { pastDuration: '15s' }, display: '15s' }, { value: { pastDuration: '30s' }, display: '30s' }, { value: { pastDuration: '60s' }, display: '1m' }, ]; <RefreshIntervalPicker timeOptions={DEFAULT_REFRESH_INTERVAL_OPTIONS} value={ DEFAULT_REFRESH_INTERVAL_OPTIONS.some((i) => i.value.pastDuration === refreshInterval) ? refreshInterval

Since merging the 1.9.0 release including the added severity[].source field, I'm not sure whether our osv.dev frontend supports the new field or not. We should investigate this, and fix it if it is not supported yet. It should be as simple as adding a severity + source on one of the test files for the local emulator, and running it with make run-website-emulator. If this is picked up after the python > go transition, it'll be make run-website-devserver

Split out of #620, where the reporter asked for "mypy and ruff for strict checks of async / blocking code". The ruff half shipped in #812 (ASYNC ruleset, enforced in CI on 3.10/3.11/3.12). The mypy half was never adopted: sdk/python/mypy.ini exists but nothing in .github/workflows/sdk-python.yml runs it, and mypy --config-file mypy.ini agentfield/ currently reports ~194 errors across ~28 files. What "done" looks like A mypy step in sdk/python CI that is required to pass. A per-module allowlist ([mypy-agentfield.<module>] with ignore_errors = True) for modules that are not yet clean, so the gate can be turned on immediately and the allowlist shrunk module by module. No # type: ignore sprinkling to get to green — fix the type or allowlist the module. Suggested order Land the CI step with everything allowlisted (zero behaviour change, proves the wiring). Clean the async-heavy modules first, since that is the reporter's concern: run_async.py, lock_utils.py, async_lifecycle.py, result_

Summary AIBrix already supports Volcano PodGroup gang scheduling through StormService.spec.template.spec.schedulingStrategy.volcanoSchedulingStrategy, but the current usage is not obvious from examples or documentation. We should add documentation and examples showing how to configure gang scheduling from the StormService entry point. Motivation StormService is the main user-facing entry for AIBrix orchestration. Users who want PD-disaggregated serving need to understand how to configure: group-level gang scheduling with minMember role-level pod minimums with Volcano minTaskMember the difference between RoleSet-level scheduling and per-role/PodSet scheduling Without examples, users may assume AIBrix has no role-aware gang support, or may configure RoleSet directly instead of using StormService. Proposed Scope Add StormService examples for: 1. Group-level gang scheduling apiVersion: orchestration.aibrix.ai/v1alpha1 kind: StormService metadata: name: sglang-pd spec: replicas: 1 s

Summary Improve the usability and correctness of Volcano gang scheduling in StormService by adding validation for invalid gang configurations and automatically injecting pod.spec.schedulerName when Volcano gang scheduling is configured. Motivation Today users configure Volcano gang scheduling through: spec: template: spec: schedulingStrategy: volcanoSchedulingStrategy: minMember: 6 minTaskMember: prefill: 4 decode: 2 However, there are two usability gaps: Invalid configurations can be accepted, such as zero or negative minTaskMember values. Users must manually set schedulerName: volcano in every role pod template, which is easy to forget. This makes StormService gang scheduling harder to use and easier to misconfigure. Proposed Scope 1. Add validation for Volcano gang fields Validate StormService.spec.template.spec.schedulingStrategy.volcanoSchedulingStrategy and the corresponding RoleSet fields. Suggested validation rul

Description This is a follow-up issue for #4335 When the Custom-All has been set, instead of all All the custom value should be used.

https://docs.github.com/en/rest/pulls/pulls?apiVersion=2022-11-28&versionId=free-pro-team%40latest&category=pulls&subcategory=stacks#merge-a-pull-request-asynchronously https://docs.github.com/en/rest/pulls/pulls?apiVersion=2022-11-28&versionId=free-pro-team%40latest&category=pulls&subcategory=stacks#get-the-result-of-an-asynchronous-merge With the introduction of Stacked Pull Requests; the only way to merge these is with the above endpoint. I see #4435 / #4436 is currently in review but this doesn't cover merging stacked PRs.

The Chinese README has drifted three sections behind the English one: $ grep -E '^#{2,3} ' README.md | wc -l 16 $ grep -E '^#{2,3} ' README.zh.md | wc -l 12 Present in README.md, absent from README.zh.md: ### Your own work, wrapped (README.md:135) — the deja stats --card SVG ### Harnesses with a package of their own (README.md:274) — the package table ## Guides (README.md:394) — the situation-based guide links (The fourth gap, ## Try it on your own history, is already #1831 — leave it to that one.) Translate the three sections and place them where the English README has them, so the two files read in the same order. Fluent Chinese matters more than a literal rendering. Verify by putting the two heading lists side by side.

Two commands, two different wrong answers to the same flag: $ deja fix "some error" --json deja: fix: unknown flag "--json" $ deja friction --json what this machine keeps tripping over — 506 sessions read ... fix refuses it. friction accepts it, ignores it and prints prose — a script reading that gets no error and no JSON either, which is the worse of the two. cmd/deja/friction.go:28-39 parses only --limit and lets anything else through; cmd/deja/fix.go:23-47 rejects it. The comment at fix.go:39 records an earlier bug where --json was swallowed into the search text, so the flag has been on this command's mind without ever being implemented. Either give both --json in the shape docs/json-output.md describes, or at minimum make friction reject what it cannot honour. A test for each. Verify with deja friction --json and deja fix "err" --json.

deja how returns the real command this machine runs for a given tool — the one output most worth piping into something else — and it has no --json: $ deja how "go test" --json deja: how: unknown flag "--json" search, blame, last, show, stats, doctor, log and bench all take it; docs/json-output.md describes the shape. Flag parsing lives at cmd/deja/how.go:38-75 and already handles --limit and --project. Add --json, follow the envelope the other commands emit, and pin it with a test. Verify with deja how "go test" --json | jq ..

deja files answers "which files did this topic touch" and prints only prose: $ deja files sometopic --json deja: files: unknown flag "--json" Its siblings all have one — search (cmd/deja/main.go:1801), blame (:1896), last (:1668), show (:561), stats, doctor, log, bench. docs/json-output.md describes the shape the others follow. The command is cmd/deja/files.go:44-83, where flag parsing already handles --limit and --project. Add --json, emit the same envelope style the other commands use, and add a test beside cmd/deja/blame_test.go's JSON case. Verify with deja files sometopic --json | jq ..

deja search takes --limit (validated 1–100 at cmd/deja/main.go:1832), and the word never appears in any generated completion script: $ deja search deja --limit 1 # works $ deja completion bash | grep -c limit 0 Search falls into the default case, which lists ten flags without this one: bash cmd/deja/completion.go:150, zsh :268, fish :281, powershell :355. Add --limit to all four. Verify with deja completion <shell> | grep -- --limit for bash, zsh, fish and powershell.

Bug Report What happened? In one of my WIKI pages, I have uploaded an image foo.png. In this page, I used this image with Markdown syntax . In the HTML rendering of this page, there is a newline / carriage return between the image/asset and the rest of the line. Version Lastest version via Docker image. Platform Desktop Web Mobile Web Running on Docker linux amd64 windows amd64 linux arm64 MacOS Expected behavior No newline between the image/asset and the rest of the text. Screenshots / recording Markdown source:  TEXT Screenshot for the HTML rendering:

I would suggest that the license card is not just empty and grey but should have a default no data to see here content.

Description Based on our users feedback: When a Stat Chart query returns many time series, Perses currently displays the individual stat values horizontally and requires the user to scroll to see the remaining values. Grafana can display the same kind of data in a more compact layout, where stat values are automatically arranged across multiple rows to fit the available panel space. This makes it much easier to get an overview when a query returns a large number of series. Perses View Grafana View Proposal It would be useful to support a compact/responsive layout where stat items can wrap into additional rows. The number of columns could be determined automatically based on: Available panel width Number of returned series Minimum readable width of each stat Once the minimum usable size is reached, scrolling could still be used as a fallback Additional Contetext From Grafana Official Docs:" Orientation => Select the stat tile layout. Choose from: Auto - Grafana selects the ideal or

Proposal Follow up to #19500 . Add native histogram version as well without the _bucket suffix. Otherwise the panel will not work when histograms are scraped as NHCB. Probably not worth doing something more complicated than just adding two new rows. For ref e.g. https://grafana.com/docs/mimir/latest/send/native-histograms/_custom_buckets/

scripts/demo/story.py draws the frames for the README GIF, and its docstring ends the recipe with an ellipsis: python3 scripts/demo/story.py --out /tmp/frames ffmpeg -framerate 20 -i /tmp/frames/%04d.png ... demo.gif Everything that decides how the GIF looks is inside those three dots. I regenerated assets/demo.gif in #1767 and had to recover the settings by comparing against the committed file: the first attempt came out 720 px wide with 320 frames against the original's 1000×467 and 192, and 833 KB against 620 KB. What the committed GIF was actually built with, recovered from ffprobe and by trying the usual knobs: python3 scripts/demo/story.py --out /tmp/frames ffmpeg -y -framerate 20 -i /tmp/frames/%04d.png \ -vf "fps=12,scale=1000:-1:flags=lanczos,palettegen=max_colors=64:stats_mode=diff" \ /tmp/palette.png ffmpeg -y -framerate 20 -i /tmp/frames/%04d.png -i /tmp/palette.png \ -lavfi "fps=12,scale=1000:-1:flags=lanczos[x];[x][1:v]paletteuse=dither=none:diff_mode=rectangle"

README.zh.md is one section short of README.md, and the gap is not at the end — it shifts everything after it: English Chinese Install 安装 What you get 能得到什么 Privacy 隐私 CLI 命令行 Supported harnesses 支持的工具 Semantic recall (optional) 可选的语义召回 Proof 证据 How it works 工作原理 FAQ 常见问题 Try it on your own history — Contributing 参与开发 License 许可 "Try it on your own history" is the section that tells a reader to point deja at their own machine and see what comes back — the one that turns a reader into a user. A Chinese reader gets everything except the invitation. The section list is only the visible half of the drift: the English file is 407 lines against 224, and some of that is legitimately shorter phrasing, but not all of it. Whoever picks this up should read the two side by side rather than only adding the missing heading. grep -c '' README.md README.zh.md grep '^## ' README.md grep