Anubis is discarding actions in Forge, force-reloading pages, losing people's work #401

New issue

Open

opened 2026-02-11 10:13:04 +00:00 by kparal · 12 comments

kparal commented 2026-02-11 10:13:04 +00:00

Copy link

I saw this first on Feb 6th, and I still see it now (Feb 11th). Every few minutes working with Forge, one of my actions get discarded, and the whole page reloads. For example, a new comment is not added (is thrown away), an edited comment is not saved (is thrown away), a new label is not added, a + button to add a PR comment to a certain line doesn't do anything, etc. Usually the whole page turns yellow for a fraction of a second, before it reloads (and loses my work). Or in some cases, where it doesn't reload, some parts turn yellow and the action doesn't work. After a page reload, I see Anubis quickly flash and then Forge works OK for some time (2-5 minutes?) before this happens again, and again.

Today I found Anubis red-handed. When trying to preview a comment, this is what I received:

Please note that I captured the whole page. I couldn't scroll up any more than this. Anubis replaces some of the Javascript response the page made, and of course the result is undefined - sometimes it reloads, sometimes it re-renders parts of the page (like this example), sometimes it shows "JSON parse error" bars at the top, like this:

This is Firefox's error console:

After this happened to me, I see it again a few minutes later when editing a comment, and then I saw it four times during reporting this very ticket. I couldn't attach a screenshot, I received errors. I opened Forge in another tab, saw Anubis, and then I could attach screenshots here. A few minutes later (still typing this), it happened again for another screenshot (this time I could upload it, but couldn't retrieve it's URL). And a few minutes later, I almost lost this text by previewing it. And when submitting this ticket, I again couldn't (had to open Forge in a new tab to let Anubis run).

So basically, every few minutes, Anubis starts replacing any Javascript calls from an open Forge page, and injecting itself into them instead. Instead of just affecting Forge page loads, it also affects any asynchronous communication that Forge does, breaking everything.

It's extremely hard to work with Forge for me at this moment, and I often lose work.

firefox-147.0.3-1.fc43.x86_64
No Adblock, Privacy badger or similar extensions. The only extension possibly affecting network traffic is Consent-O-Matic. I'll try to disable it.
Fedora 43

I saw this first on Feb 6th, and I still see it now (Feb 11th). Every few minutes working with Forge, one of my actions get discarded, and the whole page reloads. For example, a new comment is not added (is thrown away), an edited comment is not saved (is thrown away), a new label is not added, a + button to add a PR comment to a certain line doesn't do anything, etc. Usually the whole page turns yellow for a fraction of a second, before it reloads (and loses my work). Or in some cases, where it doesn't reload, some parts turn yellow and the action doesn't work. After a page reload, I see Anubis quickly flash and then Forge works OK for some time (2-5 minutes?) before this happens again, and again. Today I found Anubis red-handed. When trying to preview a comment, this is what I received:  Please note that I captured the **whole** page. I couldn't scroll up any more than this. Anubis replaces some of the Javascript response the page made, and of course the result is undefined - sometimes it reloads, sometimes it re-renders parts of the page (like this example), sometimes it shows "JSON parse error" bars at the top, like this:  This is Firefox's error console:  After this happened to me, I see it again a few minutes later when editing a comment, and then I saw it **four times** during reporting this very ticket. I couldn't attach a screenshot, I received errors. I opened Forge in another tab, saw Anubis, and then I could attach screenshots here. A few minutes later (still typing this), it happened again for another screenshot (this time I could upload it, but couldn't retrieve it's URL). And a few minutes later, I almost lost this text by previewing it. And when submitting this ticket, I again couldn't (had to open Forge in a new tab to let Anubis run). So basically, **every few minutes, Anubis starts replacing any Javascript calls from an open Forge page, and injecting itself into them instead**. Instead of just affecting Forge page loads, it also affects any asynchronous communication that Forge does, breaking everything. It's extremely hard to work with Forge for me at this moment, and I often lose work. ``` firefox-147.0.3-1.fc43.x86_64 No Adblock, Privacy badger or similar extensions. The only extension possibly affecting network traffic is Consent-O-Matic. I'll try to disable it. Fedora 43 ```

forge-anubis.png

414 KiB

forge-anusbis-error.png

42 KiB

forge-anubis-ff-console.png

158 KiB

kevin commented 2026-02-11 17:50:34 +00:00

Copy link

This may be better as an infrastructure ticket? As anubis is in front of forge and forge has not much control here. ;(

I have indeed seen reports of and seen myself anubis being much more aggressive. It seems to have started this week, but we made no changes I can think of that would affect things. ;(

I will try and figure out whats causing it.

Have you seen this on any other sites? Or only forge?

This may be better as an infrastructure ticket? As anubis is in front of forge and forge has not much control here. ;( I have indeed seen reports of and seen myself anubis being much more aggressive. It seems to have started this week, but we made no changes I can think of that would affect things. ;( I will try and figure out whats causing it. Have you seen this on any other sites? Or only forge?

gotmax23 commented 2026-02-11 18:08:43 +00:00

Copy link

I have indeed seen reports of and seen myself anubis being much more aggressive.

Indeed, I've definitely been getting more Anubis prompts over the past week or so.

In case it helps:

firefox-147.0.3-1.fc43.x86_64

I have firefox-147.0.2-1.fc42.x86_64

No Adblock, Privacy badger or similar extensions.

I do have adblock.

The only extension possibly affecting network traffic is Consent-O-Matic. I'll try to disable it.

I also have Consent-O-Matic enabled.

> I have indeed seen reports of and seen myself anubis being much more aggressive. Indeed, I've definitely been getting more Anubis prompts over the past week or so. In case it helps: > firefox-147.0.3-1.fc43.x86_64 I have firefox-147.0.2-1.fc42.x86_64 > No Adblock, Privacy badger or similar extensions. I **do** have adblock. > The only extension possibly affecting network traffic is Consent-O-Matic. I'll try to disable it. I also have Consent-O-Matic enabled.

kevin commented 2026-02-11 22:34:43 +00:00

Copy link

would it be possible to run with the network inspector up when you start seeing lots of these?

It would be nice to see what proxy you are hitting, and help me isolate it.

I dug through logs but didn't really find much that looked likely. ;(

would it be possible to run with the network inspector up when you start seeing lots of these? It would be nice to see what proxy you are hitting, and help me isolate it. I dug through logs but didn't really find much that looked likely. ;(

kevin commented 2026-02-12 00:37:20 +00:00

Copy link

Also, if you all would like to DM me your ip address I can try and look at logs for those around the approximate times you were seeing issues?

Also, if you all would like to DM me your ip address I can try and look at logs for those around the approximate times you were seeing issues?

lruzicka commented 2026-02-12 12:25:22 +00:00

Copy link

I have just encountered a very similar issue. While writing a comment on a ticket, the Anubis action caused me to lose nearly twenty minutes of work by discarding the text I had entered.

I was not reloading the page or navigating away intentionally. I simply clicked on “Comment”, after which the browser displayed a prompt asking whether I wanted to leave the page. I confirmed the prompt, and the entire comment content was lost.

This behavior is problematic, as it leads to silent data loss during normal interaction with the site. Using an external editor as a workaround is not reliable either, since pasted content can be discarded again at any time due to the same mechanism.

My IP address is not public, but I am connecting from the Red Hat Brno office. I believe traffic from these networks should not be subject to blocking or aggressive protection mechanisms.

I have just encountered a very similar issue. While writing a comment on a ticket, the Anubis action caused me to lose nearly twenty minutes of work by discarding the text I had entered. I was not reloading the page or navigating away intentionally. I simply clicked on “Comment”, after which the browser displayed a prompt asking whether I wanted to leave the page. I confirmed the prompt, and the entire comment content was lost. This behavior is problematic, as it leads to silent data loss during normal interaction with the site. Using an external editor as a workaround is not reliable either, since pasted content can be discarded again at any time due to the same mechanism. My IP address is not public, but I am connecting from the Red Hat Brno office. I believe traffic from these networks should not be subject to blocking or aggressive protection mechanisms.

kparal commented 2026-02-12 14:23:21 +00:00

Author

Copy link

@kevin wrote in #401 (comment):

This may be better as an infrastructure ticket?

Sorry :( We can't move it, it seems. Should I file it again?

Have you seen this on any other sites? Or only forge?

Only Forge.

would it be possible to run with the network inspector up when you start seeing lots of these?

I reproduced it on staging Forge. There should be much less traffic, so hopefully you can better search the log in there?

I was testing with ticket https://forge.stg.fedoraproject.org/quality/test/issues/1 . I typed some text into a new comment, and waited, until this appeared as yellow text in Firefox's network console:

Source map error: Error: JSON.parse: unexpected character at line 1 column 1 of the JSON data
Stack in the worker:parseSourceMapInput@resource://devtools/client/shared/vendor/source-map/lib/util.js:163:15
_factory@resource://devtools/client/shared/vendor/source-map/lib/source-map-consumer.js:1069:22
SourceMapConsumer@resource://devtools/client/shared/vendor/source-map/lib/source-map-consumer.js:26:12
_fetch@resource://devtools/client/shared/source-map-loader/utils/fetchSourceMap.js:83:19
Resource URL: https://forge.stg.fedoraproject.org/assets/js/index.js?v=14.0.1-4
Source Map URL: index.js.a67b897f.map

That is the indication that Anubis broke Forge, I believe. Then I hit the Preview button next to me new comment. The first time I was unlucky and the whole page refreshed. The second time I was luckier and Anubis replaced just the preview window (similar to the screenshot above). The request was going to https://forge.stg.fedoraproject.org/quality/test/markup , but instead of a proper response, Anubis content was returned. I believe this was the first improper response that was shown by Firefox's network inspector (but something else in the background must've been affected already, so that the error shown above was printed first). I saved the request as HAR (which seems to be a json dump of it), and also all requests as HAR. It's here:
anubis har
(the smaller file is the one request, the bigger file are all requests)

Does that help? Should I do something else with the network inspector?

Also, if you all would like to DM me your ip address

Private IP at home, unfortunately, or RH Brno office IP when in the office (today).

@kevin wrote in https://forge.fedoraproject.org/forge/forge/issues/401#issuecomment-392250: > This may be better as an infrastructure ticket? Sorry :( We can't move it, it seems. Should I file it again? > Have you seen this on any other sites? Or only forge? Only Forge. > would it be possible to run with the network inspector up when you start seeing lots of these? I reproduced it on staging Forge. There should be much less traffic, so hopefully you can better search the log in there? I was testing with ticket https://forge.stg.fedoraproject.org/quality/test/issues/1 . I typed some text into a new comment, and waited, until this appeared as yellow text in Firefox's network console: > Source map error: Error: JSON.parse: unexpected character at line 1 column 1 of the JSON data Stack in the worker:parseSourceMapInput@resource://devtools/client/shared/vendor/source-map/lib/util.js:163:15 _factory@resource://devtools/client/shared/vendor/source-map/lib/source-map-consumer.js:1069:22 SourceMapConsumer@resource://devtools/client/shared/vendor/source-map/lib/source-map-consumer.js:26:12 _fetch@resource://devtools/client/shared/source-map-loader/utils/fetchSourceMap.js:83:19 Resource URL: https://forge.stg.fedoraproject.org/assets/js/index.js?v=14.0.1-4 Source Map URL: index.js.a67b897f.map That is the indication that Anubis broke Forge, I believe. Then I hit the _Preview_ button next to me new comment. The first time I was unlucky and the whole page refreshed. The second time I was luckier and Anubis replaced just the preview window (similar to the screenshot above). The request was going to https://forge.stg.fedoraproject.org/quality/test/markup , but instead of a proper response, Anubis content was returned. I believe this was the first improper response that was shown by Firefox's network inspector (but something else in the background must've been affected already, so that the error shown above was printed first). I saved the request as HAR (which seems to be a json dump of it), and also all requests as HAR. It's here: [anubis har](/attachments/eb167d74-229b-4f8c-89ce-83a74f2ef9a0) (the smaller file is the one request, the bigger file are all requests) Does that help? Should I do something else with the network inspector? > Also, if you all would like to DM me your ip address Private IP at home, unfortunately, or RH Brno office IP when in the office (today).

anubis har.zip

357 KiB

lecris commented 2026-02-12 14:38:11 +00:00

Copy link

@kparal wrote in #401 (comment):

I was testing with ticket https://forge.stg.fedoraproject.org/quality/test/issues/1 . I typed some text into a new comment, and waited, until this appeared as yellow text in Firefox's network console:

Source map error: Error: JSON.parse: unexpected character at line 1 column 1 of the JSON data
Stack in the worker:parseSourceMapInput@resource://devtools/client/shared/vendor/source-map/lib/util.js:163:15
_factory@resource://devtools/client/shared/vendor/source-map/lib/source-map-consumer.js:1069:22
SourceMapConsumer@resource://devtools/client/shared/vendor/source-map/lib/source-map-consumer.js:26:12
_fetch@resource://devtools/client/shared/source-map-loader/utils/fetchSourceMap.js:83:19
Resource URL: https://forge.stg.fedoraproject.org/assets/js/index.js?v=14.0.1-4
Source Map URL: index.js.a67b897f.map

Not to hijack this too much, but I reckon this is occurring on other services as well, most likely Pagure. Ideally the fix should be a bit more generic.

At the very least why is Anubis not disabled when there is an authenticated user?

@kparal wrote in https://forge.fedoraproject.org/forge/forge/issues/401#issuecomment-392456: > I was testing with ticket https://forge.stg.fedoraproject.org/quality/test/issues/1 . I typed some text into a new comment, and waited, until this appeared as yellow text in Firefox's network console: > > > Source map error: Error: JSON.parse: unexpected character at line 1 column 1 of the JSON data > > Stack in the worker:parseSourceMapInput@resource://devtools/client/shared/vendor/source-map/lib/util.js:163:15 > > _factory@resource://devtools/client/shared/vendor/source-map/lib/source-map-consumer.js:1069:22 > > SourceMapConsumer@resource://devtools/client/shared/vendor/source-map/lib/source-map-consumer.js:26:12 > > _fetch@resource://devtools/client/shared/source-map-loader/utils/fetchSourceMap.js:83:19 > > Resource URL: https://forge.stg.fedoraproject.org/assets/js/index.js?v=14.0.1-4 > > Source Map URL: index.js.a67b897f.map Not to hijack this too much, but I reckon this is occurring on other services as well, most likely Pagure. Ideally the fix should be a bit more generic. At the very least why is Anubis not disabled when there is an authenticated user?

kevin commented 2026-02-12 22:20:02 +00:00

Copy link

@kparal wrote in #401 (comment):

@kevin wrote in #401 (comment):

This may be better as an infrastructure ticket?

Sorry :( We can't move it, it seems. Should I file it again?

I suppose it might be more visible there... so sure.

Have you seen this on any other sites? Or only forge?

Only Forge.

would it be possible to run with the network inspector up when you start seeing lots of these?

I reproduced it on staging Forge. There should be much less traffic, so hopefully you can better search the log in there?
...snip...
Does that help? Should I do something else with the network inspector?

Well, I was hoping you could look at the headers and get the proxy that you were hitting. That would allow me to look at the logs on just that proxy instead of trying to find it in the 30+ of them. ;(

Also, if you all would like to DM me your ip address

Private IP at home, unfortunately, or RH Brno office IP when in the office (today).

ok.

@lecris wrote in #401 (comment):

Not to hijack this too much, but I reckon this is occurring on other services as well, most likely Pagure. Ideally the fix should be a bit more generic.

Well, pagure is a completely different instance and it's own different anubis (container vs package).
So, thats why I was asking if anyone saw it on other sites.

Are you just suspecting it happens there? or you have seen it there?

At the very least why is Anubis not disabled when there is an authenticated user?

This was as far as I could tell 100% impossible with pagure. It always gives a cookie and the only way you can tell someone logged in vs not is to parse that cookie and see if it's a valid auth. anubis cannot do that.

That said, it looks like forge might only set a cookie when a user is authenticated... so we may be able to do this here.

@kparal wrote in https://forge.fedoraproject.org/forge/forge/issues/401#issuecomment-392456: > @kevin wrote in #401 (comment): > > > This may be better as an infrastructure ticket? > > Sorry :( We can't move it, it seems. Should I file it again? I suppose it might be more visible there... so sure. > > Have you seen this on any other sites? Or only forge? > > Only Forge. > > > would it be possible to run with the network inspector up when you start seeing lots of these? > > I reproduced it on staging Forge. There should be much less traffic, so hopefully you can better search the log in there? ...snip... > Does that help? Should I do something else with the network inspector? Well, I was hoping you could look at the headers and get the proxy that you were hitting. That would allow me to look at the logs on just that proxy instead of trying to find it in the 30+ of them. ;( > > Also, if you all would like to DM me your ip address > > Private IP at home, unfortunately, or RH Brno office IP when in the office (today). ok. @lecris wrote in https://forge.fedoraproject.org/forge/forge/issues/401#issuecomment-392458: > Not to hijack this too much, but I reckon this is occurring on other services as well, most likely Pagure. Ideally the fix should be a bit more generic. Well, pagure is a completely different instance and it's own different anubis (container vs package). So, thats why I was asking if anyone saw it on other sites. Are you just suspecting it happens there? or you have seen it there? > At the very least why is Anubis not disabled when there is an authenticated user? This was as far as I could tell 100% impossible with pagure. It always gives a cookie and the only way you can tell someone logged in vs not is to parse that cookie and see if it's a valid auth. anubis cannot do that. That said, it looks like forge might only set a cookie when a user is authenticated... so we may be able to do this here.

kevin commented 2026-02-12 23:26:25 +00:00

Copy link

Alas, forgejo seems to always set that cookie (like pagure does), so I am not sure how anubis can tell if someone is logged in or not. I suppose we could test for the cookie anyhow, with the idea that scrapers won't persist cookies...

In any case, it sounds like the issues here are:

• go to a issue
• wait some time
• try and comment/submit and get the error.

So, in staging I have set anubis to allow any POST, which I think is whats getting caught here.

Can you all see if you can see it anymore in staging? If it looks better there I can roll this out to prod too.

Alas, forgejo seems to always set that cookie (like pagure does), so I am not sure how anubis can tell if someone is logged in or not. I suppose we could test for the cookie anyhow, with the idea that scrapers won't persist cookies... In any case, it sounds like the issues here are: * go to a issue * wait some time * try and comment/submit and get the error. So, in staging I have set anubis to allow any POST, which I think is whats getting caught here. Can you all see if you can see it anymore in staging? If it looks better there I can roll this out to prod too.

kevin commented 2026-02-13 01:07:41 +00:00

Copy link

I went ahead and rolled this out to prod too since I didn't think it could break anything...

I went ahead and rolled this out to prod too since I didn't think it could break anything...

kparal commented 2026-02-13 14:35:38 +00:00

Author

Copy link

Hi, I tested it today again in https://forge.stg.fedoraproject.org/quality/test/issues/1 , and it seems to be working well! 🎉 No Anubis interfering with activities on that page, it works as expected. Thanks!

Let's keep this open for a short while to gather more feedback.

Hi, I tested it today again in https://forge.stg.fedoraproject.org/quality/test/issues/1 , and it seems to be working well! 🎉 No Anubis interfering with activities on that page, it works as expected. Thanks! Let's keep this open for a short while to gather more feedback.

kevin commented 2026-02-13 17:00:04 +00:00

Copy link

Awesome. Glad to hear it.

Awesome. Glad to hear it.

ryanlerch referenced this issue from a commit 2026-02-24 23:33:43 +00:00

proxies: allow POST for forge

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

test

docs

No results found.

Labels

Clear labels   

Backlog Status

Needs Review

Work items that have been created or updated but need review, refinement, or approval before they can be considered ready for sprint planning.

  

Backlog Status

Ready

Work items that have been reviewed, refined, and are ready to be committed to a sprint. These items have clear requirements and could be worked on immediately when capacity is available.

  

Chore

Tasks that are necessary but don't directly deliver new value to the end-user. These are internal tasks like updating a library, managing user accounts, or setting up a new service.

  

points

01

A task that is simple, small, and has very little uncertainty. It should be easy enough for any team member to pick up and complete quickly, without a lot of discussion or research.

  

points

02

This is a task that is slightly more complex or larger than a "1." It might involve two or three simple steps, but the outcome is still very clear and there's little uncertainty.

  

points

03

medium-sized task with some noticeable complexity. It might require a bit more thought or collaboration. The steps are well-defined, but it's not a trivial change.

  

points

05

a significant piece of work. It has more complexity and a higher degree of uncertainty than smaller tasks. It might require some research, a design discussion, or collaboration across multiple teams.

  

points

08

complex task with a lot of uncertainty. It's often the largest size that a team will consider for a single sprint. It likely requires a detailed breakdown and multiple team members to complete.

  

points

13

Any task that feels like it's a "13" or more is considered an Epic. These are too large and uncertain to be worked on in a single sprint.

  

Priority

High

This is for work that is critical and needs to be addressed in the next sprint. It's often for urgent bugs, important features, or a major piece of technical debt that is blocking other work.

  

Priority

Low

This is for work that is good to do but not urgent. It's a candidate for being worked on when there's extra time or when it rises in importance. It can stay in the backlog for a longer period.

  

Priority

Medium

This is for important work that should be done soon, but isn't as urgent as a high-priority item. It will likely be considered for the next 1-2 sprints.

  

Sprint Status

Blocked

Indicates the work cannot proceed. There is a dependency or an issue that is preventing the team from completing the task. This is a flag for the Scrum Master to help unblock the team.

  

Sprint Status

Done

Work items that have been completed, reviewed, and integrated. No further work is needed within the current sprint.

  

Sprint Status

In Progress

This label is for work that a developer is actively working on. This is usually what you'll see on the "In Progress" column of your project board.

  

Sprint Status

Review

This indicates that the work is complete, but it is now in a review state. This could mean a peer code review, a QA check, or a review by the Product Owner.

  

Sprint Status

To Do

Work items that are committed to the sprint but haven't been started yet. These items are ready to be picked up by team members.

  

Technical Debt

work that improves the codebase without adding new features. It's work that pays down the "debt" you've accumulated, such as refactoring a messy piece of code, improving test coverage.

  

Work Item

Bug

Issues where the system is not working as intended or designed. Bugs represent deviations from expected behavior.

  

Work Item

Epic

  

Work Item

Spike

  

Work Item

Task

  

Work Item

User Story

  

Backlog Status

Needs Review

Work items that have been created or updated but need review, refinement, or approval before they can be considered ready for sprint planning.

  

Backlog Status

Ready

Work items that have been reviewed, refined, and are ready to be committed to a sprint. These items have clear requirements and can be worked on immediately when capacity is available.

  

chore

Work that needs to be done but doesn't add new functionality or fix bugs. Maintenance tasks that keep the system running smoothly and the codebase clean.

  

documentation

Work focused on creating, updating, or improving documentation for users, developers, or system administrators.

  

points

01

A task that is simple, small, and has very little uncertainty. It should be easy enough for any team member to pick up and complete quickly, without a lot of discussion or research.

  

points

02

This is a task that is slightly more complex or larger than a "1." It might involve two or three simple steps, but the outcome is still very clear and there's little uncertainty.

  

points

03

Medium-sized task with some noticeable complexity. It might require a bit more thought or collaboration. The steps are well-defined, but it's not a trivial change.

  

points

05

A significant piece of work. It has more complexity and a higher degree of uncertainty than smaller tasks. It might require some research, a design discussion, or collaboration across multiple teams.

  

points

08

Complex task with a lot of uncertainty. It's often the largest size that a team will consider for a single sprint. It likely requires a detailed breakdown and multiple team members to complete.

  

points

13

Any task that feels like it's a "13" or more is considered an Epic. These are too large and uncertain to be worked on in a single sprint and should be broken down.

  

Priority

High

This is for work that is critical and needs to be addressed in the next sprint. It's often for urgent bugs, important features, or a major piece of technical debt that is blocking other work.

  

Priority

Low

This is for work that is good to do but not urgent. It's a candidate for being worked on when there's extra time or when it rises in importance. It can stay in the backlog for a longer period.

  

Priority

Medium

This is for important work that should be done soon, but isn't as urgent as a high-priority item. It will likely be considered for the next 1-2 sprints.

  

Sprint Status

Blocked

Work items that cannot progress due to external dependencies, blockers, or issues that need resolution.

  

Sprint Status

Done

Work items that have been completed, reviewed, and integrated. No further work is needed within the current sprint.

  

Sprint Status

In Progress

Work items currently being worked on by a team member. Active development, research, or implementation is happening.

  

Sprint Status

Review

Work items that are complete but need review, testing, or approval before being marked as done.

  

Sprint Status

To Do

Work items that are committed to the sprint but haven't been started yet. These items are ready to be picked up by team members.

  

Technical Debt

Work that addresses shortcuts, workarounds, or suboptimal implementations that were done previously to meet deadlines. These items improve code quality, maintainability, or performance without adding new features.

  

Work Item

Bug

Issues where the system is not working as intended or designed. Bugs represent deviations from expected behavior.

  

Work Item

Epic

Large initiatives that are broken down into multiple smaller work items (user stories, tasks, bugs). Epics represent significant features or projects that span multiple sprints.

  

Work Item

Spike

Time-boxed research, investigation, or proof-of-concept work to reduce uncertainty or explore solutions. Spikes help inform future development decisions.

  

Work Item

Task

Used to break down larger user stories into smaller, manageable implementation pieces. They focus on the specific technical steps needed to deliver the user story's value.

  

Work Item

User Story

User-facing features or functionality that can be framed from a user perspective, describing what someone wants to accomplish and why.

No labels

Backlog Status

Needs Review

Backlog Status

Ready

Chore

points

01

points

02

points

03

points

05

points

08

points

13

Priority

High

Priority

Low

Priority

Medium

Sprint Status

Blocked

Sprint Status

Done

Sprint Status

In Progress

Sprint Status

Review

Sprint Status

To Do

Technical Debt

Work Item

Bug

Work Item

Epic

Work Item

Spike

Work Item

Task

Work Item

User Story

Backlog Status

Needs Review

Backlog Status

Ready

chore

documentation

points

01

points

02

points

03

points

05

points

08

points

13

Priority

High

Priority

Low

Priority

Medium

Sprint Status

Blocked

Sprint Status

Done

Sprint Status

In Progress

Sprint Status

Review

Sprint Status

To Do

Technical Debt

Work Item

Bug

Work Item

Epic

Work Item

Spike

Work Item

Task

Work Item

User Story

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

5 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

forge/forge#401

No description provided.