Traceback: Timeout waiting for data

[SeDi343]

Describe the bug
Content is not loading with cloud = False, api version = 2 getting followingTraceback:

> JIRA_TUI_CONFIG_FILE=./config.yaml jiratui ui
Failed to get cell size via escape sequence, assuming VT340 sizes
Traceback (most recent call last):
  File "/home/user/.local/share/pipx/venvs/jiratui/lib/python3.12/site-packages/textual_image/_terminal.py", line 64, in get_cell_size
    with capture_terminal_response("\x1b[", "t", 0.1) as response:
  File "/usr/lib/python3.12/contextlib.py", line 144, in __exit__
    next(self.gen)
  File "/home/user/.local/share/pipx/venvs/jiratui/lib/python3.12/site-packages/textual_image/_terminal.py", line 117, in capture_terminal_response
    response.sequence += read(stdin, 1, timeout)
                         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/user/.local/share/pipx/venvs/jiratui/lib/python3.12/site-packages/textual_image/_posix.py", line 34, in read
    raise TimeoutError("Timeout waiting for data")
TimeoutError: Timeout waiting for data

config contains:

jira_api_username: 'myuser@company.com'
jira_api_token: 'MY_BEAUTIFUL_API_TOKEN'
jira_api_base_url: 'https://jira.company.com'
jira_api_version: 2
cloud: False

To Reproduce
Steps to reproduce the behavior:

1. Execute JIRA_TUI_CONFIG_FILE=./config.yaml jiratui ui for jira api version 2 and cloud false
2. Get Traceback and no data

Expected behavior
No Traceback and data in jiratui ui

Screenshots

Desktop (please complete the following information):

• OS: Ubuntu 24.04.3 LTS x86_64, 6.8.0-86-generic
• Version: 1.5.0

[whyisdifficult]

@SeDi343 can you check the jiratui logs to see what could be happening?

[dennym]

Just to give my 5cents. I am running into the same issue and has nothing to do with config or settings. This just straight up occurs when installing and starting initially. My guess is that it tries to initialize some terminal rendering functionality and fails on that.
My setup is Ubuntu@WSL

$ jiratui

Failed to get cell size via escape sequence, assuming VT340 sizes
Traceback (most recent call last):
  File "/home/fff/.local/share/uv/tools/jiratui/lib/python3.11/site-packages/textual_image/_terminal.py", line 64, in get_cell_size
    with capture_terminal_response("\x1b[", "t", 0.1) as response:
  File "/home/fff/.pyenv/versions/3.11.2/lib/python3.11/contextlib.py", line 144, in __exit__
    next(self.gen)
  File "/home/fff/.local/share/uv/tools/jiratui/lib/python3.11/site-packages/textual_image/_terminal.py", line 117, in capture_terminal_response
    response.sequence += read(stdin, 1, timeout)
                         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/fff/.local/share/uv/tools/jiratui/lib/python3.11/site-packages/textual_image/_posix.py", line 34, in read
    raise TimeoutError("Timeout waiting for data")
TimeoutError: Timeout waiting for data

According to this https://pypi.org/project/textual-image/ it relates that you require the right combination of terminal software and image rendering standard (also scroll past the table to get hints for each term). Since I use WSL my issue is that I can only rely on sixel (libsixel ) and need to upgrade my Windows terminal to a more recent version.

In my experience image rendering in terminals is always wonky and shouldn't be in jiratui since this will be an issue for many new users. Or at least a featureflag which tests if image rendering works and then only load it conditionally and put a placeholder when it is not supported.

[SeDi343]

@SeDi343 can you check the jiratui logs to see what could be happening?

Where are they located? I have it since the last update to 1.5.0

[SeDi343]

But it anyway was never able to load any content. Did not connect to our jira instance at all.

[dennym]

Have you read my comment and followed this path to fix it on your end? Timeout does not mean "couldn't poll from jira".... It means that the runtime timeouted. As clearly stated in your stacktrace:

[SeDi343]

Have you read my comment and followed this path to fix it on your end? Timeout does not mean "couldn't poll from jira".... It means that the runtime timeouted. As clearly stated in your stacktrace:

Must have something to do with the latest jiratui. I installed it via pipx. I did nothing other than updating it from previous version to newest version running pipx upgrade-all.

I did not have this error in previous version but i still had no connection to my jira instance at all also on previous versions

[dennym]

What was your previous version? Because the image rendering and the actual failing dependency got introduced with 1.3 but the raise triggering might have been introduced later from something else.

But what you actually used before does not matter.... Just check the dependency which is failing and linked in previous comment and you can easily fix this yourself. This is nothing the jiratui can fix for you since you need to have the required dependencies on your system so textual-image can function proper.

Basically the main question you need to answer is what terminal you use.

[whyisdifficult]

@dennym

In my experience image rendering in terminals is always wonky and shouldn't be in jiratui since this will be an issue for many new users. Or at least a featureflag which tests if image rendering works and then only load it conditionally and put a placeholder when it is not supported.

This is a good point. It may be better to make the image-support feature optional and let the users enable it via the config. This should ensure that any issues with image rendering stays contained.

I will think of a way to support this optionally in the next releases.

[whyisdifficult]

@SeDi343 can you check the jiratui logs to see what could be happening?

Where are they located? I have it since the last update to 1.5.0

JiraTUI uses XDG for the location of files (config, logs, etc.).

• For Windows the logs should be located under C:\Users\<username>\AppData\Local
• On MacOS/Linux the logs should be under
  • ~/.local/state or,
  • ~/Library/Application Support

The log file by default is called jiratui.log

[whyisdifficult]

@SeDi343 , can you give this a try? This is just to rule out issues. I don't expect this to be a connectivity issue to the Jira instance though. The reason to try is that in the first message you posted an image where we can see that the app runs but, you don't see any data. I'm trying to make sure that the app can reach the instance. Again, I doubt this is the issue but, let's check.

curl --request GET \
  --url 'https://your-domain.atlassian.net/rest/api/2/serverInfo' \
  --user 'email@example.com:<api_token>' \
  --header 'Accept: application/json'

[SeDi343]

I get a response but seems like the authentication is not working properly. I get 401 Errors. Also the Log is full of it.

[whyisdifficult]

I get a response but seems like the authentication is not working properly. I get 401 Errors. Also the Log is full of it.

That explains the lack of data.

[cr2007]

@whyisdifficult
I am also facing the same issue, even with a Cloud Jira account with all the API tokens setup.

I just recently installed JiraTUI via uv tool install, and added the YAML configuration directly via $XDG_CONFIG_HOME/jiratui/config.yaml.

When I tried to normally normally run the command, it shows the error mentioned above, followed by the help commands.

I also ran the curl command you provided in a previous comment:

curl --request GET
--url 'https://your-domain.atlassian.net/rest/api/2/serverInfo'
--user 'email@example.com:<api_token>'
--header 'Accept: application/json'

and it is showing a success from my end, I am able to see the URL details, version numbers, build information, etc.

Could you please look into this matter? This tool definitely does look very promising to use compared to the web GUI version.

[whyisdifficult]

@cr2007 what do you see when you run the following command?

jiratui issues search -p <the-key-of-a-project>

[whyisdifficult]

@dennym @SeDi343 @cr2007 the latest version 1.6.1 includes a config variable to disable support for images. By default is on but you can disable image support so you don't have the issue that was reported above with images.