github-starred/cobalt
2
0
Fork 0
mirror of https://github.com/imputnet/cobalt.git synced 2026-05-24 13:11:06 -05:00
Code Issues 2.2k Packages Projects Releases Wiki Activity

Error.api.fetch.empty occurs for single-photo Instagram links #717

New Issue
Closed
opened 2025-11-09 09:56:40 -06:00 by GiteaMirror · 2 comments
GiteaMirror commented 2025-11-09 09:56:40 -06:00
Owner
Copy Link

Originally created by @aiovin on GitHub (Feb 16, 2025).

problem description

When making a request to the API with a link to an Instagram post containing only a single photo:
curl -X POST "http://localhost:9000/" -H "Content-Type: application/json" -H "Accept: application/json" -d '{"url": "https://www.instagram.com/p/DFQeD9JNv7o/"}'

I encounter the following response from the API:
{"status":"error","error":{"code":"error.api.fetch.empty"}}

Currently, this issue is observed only on one server, while the same request works correctly from another server.

Other requests to Instagram, such as this one:
curl -X POST "http://localhost:9000/" -H "Content-Type: application/json" -H "Accept: application/json" -d '{"url": "https://www.instagram.com/p/DFu4tXpN6yp/"}'
(i.e., posts with multiple photos) are executed correctly on the problematic server.

No issues are observed on the official cobalt.tool website or on public instances with single-photo ig links.

The docker compose logs do not output any information regarding the requests and responses to the API, so perhaps the logs should be checked elsewhere to get more details about why this response is occurring, but I'm not sure where.

If I’m not mistaken, such requests to the cobalt API used to return links like http://localhost:9000/tunnel... I remember this because the issue didn’t appear immediately but only after about a day. Is it possible to disable this kind of tunneling if the problem is related to it?

your instance configuration

services:
  cobalt-api:
    image: ghcr.io/imputnet/cobalt:10

    init: true
    read_only: true
    restart: unless-stopped
    container_name: cobalt-api

    ports:
      # - 9000:9000/tcp
      - 127.0.0.1:9000:9000

    environment:
      API_URL: "http://localhost:9000"

      # COOKIE_PATH: "/cookies.json"
      API_KEY_URL: "file:///keys.json"
      API_AUTH_REQUIRED: 1

    labels:
      - com.centurylinklabs.watchtower.scope=cobalt

    volumes:
      # - ./cookies.json:/cookies.json
      - ./keys.json:/keys.json:ro

  watchtower:
    image: ghcr.io/containrrr/watchtower
    restart: unless-stopped
    command: --cleanup --scope cobalt --interval 900 --include-restarting
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
Originally created by @aiovin on GitHub (Feb 16, 2025). ### problem description When making a request to the API with a link to an Instagram post containing only a single photo: `curl -X POST "http://localhost:9000/" -H "Content-Type: application/json" -H "Accept: application/json" -d '{"url": "https://www.instagram.com/p/DFQeD9JNv7o/"}'` I encounter the following response from the API: `{"status":"error","error":{"code":"error.api.fetch.empty"}}` Currently, this issue is observed only on one server, while the same request works correctly from another server. Other requests to Instagram, such as this one: `curl -X POST "http://localhost:9000/" -H "Content-Type: application/json" -H "Accept: application/json" -d '{"url": "https://www.instagram.com/p/DFu4tXpN6yp/"}'` (i.e., posts with multiple photos) are executed correctly on the problematic server. No issues are observed on the official cobalt.tool website or on public instances with single-photo ig links. The `docker compose logs` do not output any information regarding the requests and responses to the API, so perhaps the logs should be checked elsewhere to get more details about why this response is occurring, but I'm not sure where. If I’m not mistaken, such requests to the cobalt API used to return links like `http://localhost:9000/tunnel...` I remember this because the issue didn’t appear immediately but only after about a day. Is it possible to disable this kind of tunneling if the problem is related to it? ### your instance configuration ```shell services: cobalt-api: image: ghcr.io/imputnet/cobalt:10 init: true read_only: true restart: unless-stopped container_name: cobalt-api ports: # - 9000:9000/tcp - 127.0.0.1:9000:9000 environment: API_URL: "http://localhost:9000" # COOKIE_PATH: "/cookies.json" API_KEY_URL: "file:///keys.json" API_AUTH_REQUIRED: 1 labels: - com.centurylinklabs.watchtower.scope=cobalt volumes: # - ./cookies.json:/cookies.json - ./keys.json:/keys.json:ro watchtower: image: ghcr.io/containrrr/watchtower restart: unless-stopped command: --cleanup --scope cobalt --interval 900 --include-restarting volumes: - /var/run/docker.sock:/var/run/docker.sock ```
GiteaMirror added the instance hosting help label 2025-11-09 09:56:40 -06:00
GiteaMirror commented 2025-11-09 09:56:42 -06:00
Author
Owner
Copy Link

@dumbmoron commented on GitHub (Feb 16, 2025):

can’t reproduce on cobalt.tools, which means it’s probably not anything related to codebase

@dumbmoron commented on GitHub (Feb 16, 2025): can’t reproduce on cobalt.tools, which means it’s probably not anything related to codebase
GiteaMirror commented 2025-11-09 09:56:42 -06:00
Author
Owner
Copy Link

@dumbmoron commented on GitHub (Feb 16, 2025):

Currently, this issue is observed only on one server, while the same request works correctly from another server.
…
If I’m not mistaken, such requests to the cobalt API used to return links like http://localhost:9000/tunnel... I remember this because the issue didn’t appear immediately but only after about a day. Is it possible to disable this kind of tunneling if the problem is related to it?

it’s unrelated, probably ip reputation

@dumbmoron commented on GitHub (Feb 16, 2025): > Currently, this issue is observed only on one server, while the same request works correctly from another server. > … > If I’m not mistaken, such requests to the cobalt API used to return links like `http://localhost:9000/tunnel...` I remember this because the issue didn’t appear immediately but only after about a day. Is it possible to disable this kind of tunneling if the problem is related to it? it’s unrelated, probably ip reputation
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
3rd party app support
bug
can reproduce
can't reproduce
documentation
duplicate
feature request
help wanted
instance hosting help
invalid
main instance issue
need more info
needs fixing
next major
not an issue
pull-request
Mirrored from GitHub Pull Request
 question
region lock issue
security
service request
skill issue
web ui
No Label instance hosting help
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/cobalt#717
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?