Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No Image Output or Preview Received from runpod-fooocus-api on Completed Requests #33

Open
DisantHoridnt opened this issue Aug 12, 2024 · 6 comments
Labels
info needed Further information is requested

Comments

@DisantHoridnt
Copy link

We are experiencing issues while testing the POST request to the https://api.runpod.ai/v2/secret_key/runsync endpoint. Our serverless setup utilizes the 3wad/runpod-fooocus-api:0.4.1.0-standalone image, and despite successfully completing the request, we are not receiving the expected job results or previews.

Current Behavior

When sending the POST request to initiate a text-to-image generation, the response indicates that the status is COMPLETED, but the job_result and job_step_preview fields remain null. This issue prevents us from retrieving any image data or previews.

Request Details

Endpoint: https://api.runpod.ai/v2/secret_key/runsync

Request Body:

{
  "input": {
    "api_name": "txt2img",
    "prompt": "A ball",
    "negative_prompt": "",
    "style_selections": [],
    "performance_selection": "Speed",
    "aspect_ratios_selection": "1024*1024",
    "image_number": 1,
    "image_seed": -1,
    "save_extension": "png",
    "require_base64": true,
    "async_process": true,
    "preview_url": "https:/endpoint/previews",
    "preview_headers": "{"Cookie":"foo=bar"}"
  }
}

Response Received:

{
  "delayTime": 391,
  "executionTime": 48,
  "id": "sync-184706f0-8300-482a-a424-7548483769fe-u1",
  "output": {
    "job_id": "d206eafb-c69e-4f75-b1de-ad0b0e7ae49b",
    "job_progress": 0,
    "job_result": null,
    "job_stage": "WAITING",
    "job_status": null,
    "job_step_preview": null,
    "job_type": "Text to Image"
  },
  "status": "COMPLETED"
}

Expected Behavior

We expect the following upon successful request completion:

  • job_result to contain the image or data URL(s).
  • job_step_preview to provide incremental previews if available.
  • A job_progress update reflecting the progress of the job beyond 0.
  • An indication of success or failure in the job_status field.

Environment Details

  • Image Used: 3wad/runpod-fooocus-api:0.4.1.0-standalone
  • Testing Tools: Postman (or relevant API testing tool)

Steps to Reproduce

  1. Set up the serverless function using the 3wad/runpod-fooocus-api:0.4.1.0-standalone image.
  2. Send a POST request to the endpoint https://api.runpod.ai/v2/secret_key/runsync with the provided request body.
  3. Observe the response and note the absence of expected job results and previews.

Additional Information

  • We have ensured that the preview_url and preview_headers as provided on the docs , but no such data is arriving at our endpoint.
  • Any insights into whether this is an API misconfiguration or a bug in the image would be greatly appreciated.

Request for Help

We are seeking assistance to:

  • Identify potential misconfigurations in our request or setup.
  • Understand any additional requirements for successful API operation.
  • Resolve the issue to retrieve and handle image generation results correctly.
@davefojtik
Copy link
Owner

When using /runsync with "async_process": true the NULL in outputs is expected because of how the async_process works. The intended/recommended use for the previews is:

  • /run - when using an async request, you get a response from RunPod about a successfully queued async task instantly, not as the job finishes
  • "async_process": true - allows Fooocus API to do other things while the image is generating "in the background"
  • "preview_url" - periodically internally checks the job status containing the preview or final image and sends it as a POST request to your specified URL
  • (Optional) "preview_interval" and "preview_headers" - sets how often it's checked & sent and if it should contain any request headers.

The /runsync would also normally work and you would see the requests coming to your endpoint anyway. The problem is probably in the JSON format of the body you're sending. Github marked it for you with a red colour where the error is, and the API should return the following:

{"Error": "bad request: body: unmarshaling JSON: invalid character 'C' after object key:value pair"}

The valid JSON is either:

"preview_headers": {"Cookie":"foo=bar"}

for V2 endpoints, or

"preview_headers": "{\"Cookie\":\"foo=bar\"}"

for V1 endpoints that use multipart/form-data. See request_examples.js


When corrected, a request like this:

{
  "input": {
    "api_name": "txt2img",
    "prompt": "A ball",
    "negative_prompt": "",
    "style_selections": [],
    "performance_selection": "Speed",
    "aspect_ratios_selection": "1024*1024",
    "image_number": 1,
    "image_seed": -1,
    "save_extension": "png",
    "require_base64": true,
    "async_process": true,
    "preview_url": "https://webhook.site/your-generated-uuid",
    "preview_headers": {"Cookie":"foo=bar"}
  }
}

is sending previews and final images to the testing endpoint just fine. If you still don't see requests coming in with JSON like this on your endpoint, you should check if it's working properly.

@DisantHoridnt
Copy link
Author

Thank you for taking your time to respond to the issue despite having a busy schedule.

Issue:

  • Despite using the /run endpoint with "async_process": true, the output remains NULL, and I'm not receiving any previews at the specified endpoint https://endpoint/previews.
  • I have verified that my endpoint works correctly when tested independently.

Current Setup:

  • API Request:

    {
      "input": {
        "api_name": "txt2img",
        "prompt": "A ball",
        "negative_prompt": "",
        "style_selections": [],
        "performance_selection": "Speed",
        "aspect_ratios_selection": "1024*1024",
        "image_number": 1,
        "image_seed": -1,
        "save_extension": "png",
        "require_base64": true,
        "async_process": true,
        "preview_url": "https://endpoint/previews",
        "preview_headers": {
         "asset_id": "123",
         "preview_data": "This is a preview data example"
       }
      }
    }
  • Response:

    {
      "delayTime": 439,
      "executionTime": 43,
      "id": "4647ba62-1743-4695-b7a1-4b9d9e057289-u1",
      "output": {
        "job_id": "601c4d85-e8f7-4998-86c1-9859af45a309",
        "job_progress": 0,
        "job_result": null,
        "job_stage": "WAITING",
        "job_status": null,
        "job_step_preview": null,
        "job_type": "Text to Image"
      },
      "status": "COMPLETED"
    }

Potential Concerns:

  1. Preview Headers:

    • I suspect there might be an issue with how the preview_headers are structured or being processed. The previews endpoint expects such a request:
      {
        "asset_id": "123",
        "preview_data": "This is a preview data example"
      }
      How should I structure the preview_headers?
  2. Output Handling:

    • The response consistently shows job_result as null, and there are no updates or previews sent to my endpoint.

Request for Assistance:

Could you please provide guidance on the following:

  • Correct Structuring of preview_headers: Are there specific headers required for the API to properly send previews?
  • Ensuring Output Delivery: How can I ensure that the output is not NULL and previews are being sent to the specified preview_url?

@davefojtik
Copy link
Owner

davefojtik commented Aug 13, 2024

When using /run, the response should not contain the same structure as when using /runsync. It looks more like this:

{
    "id": "job-uuid",
    "status": "IN_QUEUE"
}

Your headers look ok and are completely optional. No custom headers should be required to make this work. I send that exact API request via Postman just with "preview_url" being the testing endpoint you can try for example at webhook.site. Example:

"preview_url": "https://webhook.site/your-generated-uuid"

and I get both the headers:
image
and expected payloads:
image

It seems I still can't reproduce the problem you're facing. Please try running the requests with some online testing endpoint URLs like I mentioned to exclude possible problems with the HTTP server you're using. Also please observe the active worker's logs at your RunPod serverless endpoint dashboard for any potential errors after you send the request.

Hopefully, we'll be able to pinpoint the problem better after that.

@davefojtik davefojtik added the info needed Further information is requested label Aug 16, 2024
@DisantHoridnt
Copy link
Author

Hello @davefojtik,

Thank you for taking the time to respond to the issue. I was able to adjust the request body, and the image generation was successful.

I now have an issue where I want to incorporate my own fine-tuned request body. Below is the request structure I’m using:

input: {
  api_name: "txt2img",
  prompt: `${prompt}`,
  negative_prompt: "",
  style_selections: [],
  performance_selection: "Speed", // very important
  aspect_ratios_selection: "1024*1024",
  image_number: 1,
  image_seed: -1,
  sharpness: 2,
  guidance_scale: 2, // very important
  input_image: "",
  uov_method: "",
  upscale_value: "",
  image_prompts: [],
  base_model_name: "DreamShaperXL_Lightning-SFW.safetensors", // very important
  refiner_model_name: "None",
  refiner_switch: 0.5,
  loras: [
    {
      enabled: true,
      model_name: "sd_xl_offset_example-lora_1.0.safetensors",
      weight: 0.1
    },
    { enabled: false, model_name: "None", weight: 1.0 },
    { enabled: false, model_name: "None", weight: 1.0 },
    { enabled: false, model_name: "None", weight: 1.0 },
    { enabled: false, model_name: "None", weight: 1.0 }
  ],
  advanced_params: {
    adaptive_cfg: 7, // very important
    adm_scaler_end: 0.3,
    adm_scaler_negative: 0.8,
    adm_scaler_positive: 1.5,
    canny_high_threshold: 128,
    canny_low_threshold: 64,
    controlnet_softness: 0.25,
    debugging_cn_preprocessor: false,
    debugging_inpaint_preprocessor: false,
    disable_intermediate_results: true,
    disable_preview: true,
    disable_seed_increment: false,
    freeu_b1: 1.01,
    freeu_b2: 1.02,
    freeu_enabled: false,
    freeu_s1: 0.99,
    freeu_s2: 0.95,
    inpaint_disable_initial_latent: false,
    inpaint_engine: "v2.6",
    inpaint_erode_or_dilate: 0,
    inpaint_mask_upload_checkbox: false,
    inpaint_respective_field: 1,
    inpaint_strength: 1,
    invert_mask_checkbox: false,
    mixing_image_prompt_and_inpaint: false,
    mixing_image_prompt_and_vary_upscale: false,
    overwrite_height: -1,
    overwrite_step: 6, // very important
    overwrite_switch: -1,
    overwrite_upscale_strength: -1,
    overwrite_vary_strength: -1,
    overwrite_width: -1,
    refiner_swap_method: "joint",
    default_sampler: "dpmpp_sde_gpu", // very important
    scheduler_name: "karras", // very important
    skipping_cn_preprocessor: false,
    black_out_nsfw: false
  },
  save_extension: "png",
  read_wildcards_in_order: false,
  require_base64: true,
  async_process: true,
  preview_url: "https://.../.."
}

Unfortunately, setting the request body like the one above does not generate any images. However, setting it as shown below generates an image successfully:

input: {
  api_name: "txt2img",
  prompt: `${prompt}, (masterpiece) (best quality) (detailed) (8k) (cinematic lighting) (sharp focus) (intricate)`,
  negative_prompt: "",
  style_selections: [],
  performance_selection: "Speed",
  aspect_ratios_selection: "1024*1024",
  image_number: 1,
  image_seed: -1,
  save_extension: "png",
  require_base64: true,
  async_process: true,
  preview_url: "https://../.."
}

I’d appreciate any guidance you can offer on how to properly configure the fine-tuned request body to work with your API.

Thank you in advance!

@davefojtik
Copy link
Owner

Hello. Glad to hear you made it work!

The problem in your fine-tuned request body is in advanced_params > disable_preview: true that tells Fooocus itself to disable the previews. The handler then receives nothing it could send - thus, the null value again. Setting it to false solves it.

@DisantHoridnt
Copy link
Author

Thank you for the response. I do appreciate it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
info needed Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants