Problem Summary: Hugging Face Space Running, but Line Webhook Verification Fails with No Logs

[Wendy-Tsai]

Problem Summary: Hugging Face Space Running, but Line Webhook Verification Fails with No Logs

This document summarizes the issue encountered with a Flask application deployed on Hugging Face Spaces, specifically concerning the Line Bot Webhook verification.

Space Details:

• Space URL: https://huggingface.co/spaces/Wendy-Tsai/linebot-final

Current Status:

• The Hugging Face Space is in a running state.
• The deployed Flask application is accessible via a web browser.
  • Navigating to https://Wendy-Tsai-linebot-final.hf.space/ returns “Hello, I am running! (Flask App on Hugging Face Spaces)”.
  • Navigating to https://Wendy-Tsai-linebot-final.hf.space/callback returns “OK”.
  • This confirms that the Gunicorn server and the Flask application are correctly running within the container and are externally accessible via the base URL and the /callback endpoint for GET requests.

The Core Problem:

• Line Developers Console Webhook Verification Fails: When attempting to verify the Webhook URL (https://Wendy-Tsai-linebot-final.hf.space/callback ) in the Line Developers Console, the verification consistently fails.
• Crucially, No Corresponding Logs in Space Container: Despite the verification failure, there are no log entries in the Hugging Face Space’s “Container Logs” indicating that a request (specifically, a GET or POST from LineBotWebhook) reached the application. This is the most critical piece of evidence.

Diagnostic Steps Performed (and their outcomes):

1. Dockerfile Validation:

• The Dockerfile has been repeatedly reviewed and corrected to ensure proper Python 3.10 slim base, installation of all necessary system dependencies (git , git-lfs , ffmpeg , libsm6 , libxext6 , cmake , rsync , libgl1-mesa-glx , build-essential , libffi-dev , libssl-dev ), correct WORKDIR , requirements.txt installation, file copying, and directory permissions (/app/static/uploads , /app/data , /tmp ).
• The EXPOSE 7860 is present.
• The CMD instruction uses the Shell Form CMD gunicorn ... "0.0.0.0:${PORT:-7860}" app:app (and a more robust logging version was also tried) to ensure Gunicorn binds to the correct port.
• Outcome: Docker image builds successfully, and Gunicorn is configured to listen on 0.0.0.0:7860 .

2. Application Code (app.py ) Validation:

• The app.py has been updated to use Line Bot SDK v3.
• A / route for general health checks is implemented, returning “Hello, I am running! (…)”.
• The /callback route handles both POST and GET requests.
  • For GET requests to /callback , it returns “OK”.
  • For POST requests to /callback , it includes logic to handle empty events arrays (which Line sends for certain verifications/pushes) by returning “OK” directly.
• Extensive logging has been added to both / and /callback routes to capture request methods, URLs, and all headers.
• Outcome: Application logic appears sound and is designed to correctly respond to Line’s verification requests.

3. External Webhook Test (webhook.site ):

• The Line Developers Console’s Webhook URL was temporarily changed to a webhook.site URL.
• When “Verify” was clicked in Line Developers Console, webhook.site successfully received a POST request from LineBotWebhook/2.0 containing an empty events array.
• Outcome: This unequivocally proves that Line’s webhook verification mechanism is functional and correctly sending POST requests.

Conclusion:

Given that:

1. The Hugging Face Space is running and accessible via browser.
2. The application code is designed to handle Line’s verification requests (both GET to / and GET /POST to /callback ).
3. Line is definitively sending the POST webhook verification request (confirmed by webhook.site ).
4. There is no corresponding request logged in the Hugging Face Space container , even with aggressive logging in the CMD .

The problem is almost certainly at the Hugging Face Spaces platform level . It appears that the incoming POST webhook requests from Line are being intercepted, blocked, or dropped by Hugging Face Spaces’ internal network, proxy, or firewall before they ever reach the user’s container. This might be due to specific HTTP headers, user-agents, or IP ranges used by Line that are being unintentionally filtered.

Recommended Action:

It is strongly recommended to contact Hugging Face Spaces official support and provide them with all the detailed information above, especially the webhook.site proof and the lack of corresponding logs in the Space. They will have access to deeper network logs and infrastructure configurations to diagnose why Line’s specific requests are not reaching the application container.

[John6666]

When accessing Hugging Face Spaces from outside, the port is quite limited and seems to change occasionally.

Open port for space to connect to PostgreSQL

Hi @chris-rannou, Could you open the port 5432 for this space: Defi Ai 2022 - a Hugging Face Space by vnghia as I need to connect to a PostgreSQL database ? Thank you very much !

Webhook to receive twilio whatsapp messages

How to create webhooks in hf gradio app to receive user initiated Whatsapp user message via twilio through webhook as a http post. can flask be used? tried below code but it doesnt work: import gradio as gr from flask import Flask, request from twilio.twiml.messaging_response import MessagingResponse app = Flask(name) @app.route(“/webhook”, methods=[“POST”]) def handle_webhook(): # Get the incoming message from Twilio message = request.form[“Body”] # Perform any desired processing or …