Harden auth, AI tutor, payments, and subscriptions
This commit is contained in:
@@ -1,9 +1,12 @@
|
||||
import logging
|
||||
|
||||
from django.db import IntegrityError, transaction
|
||||
from django.http import Http404
|
||||
from django.shortcuts import get_object_or_404
|
||||
from django.utils import timezone
|
||||
from drf_spectacular.types import OpenApiTypes
|
||||
from drf_spectacular.utils import OpenApiParameter, extend_schema
|
||||
from rest_framework.exceptions import Throttled
|
||||
from rest_framework.exceptions import APIException, Throttled
|
||||
from rest_framework.permissions import IsAuthenticated
|
||||
from rest_framework.response import Response
|
||||
from rest_framework.views import APIView
|
||||
@@ -18,17 +21,79 @@ from .serializers import (
|
||||
FeedbackResponseSerializer,
|
||||
)
|
||||
|
||||
logger = logging.getLogger(__name__)
|
||||
|
||||
DAILY_AI_QUOTA = 15
|
||||
|
||||
|
||||
def generate_tutor_answer(user_question: str, grade_id, lesson_id) -> tuple[str, list[str]]:
|
||||
def _is_db_ref_id(value) -> bool:
|
||||
"""
|
||||
استاب پاسخ AI Tutor. اینجا محل اتصال به مدل واقعی (مثلاً Claude API از طریق
|
||||
Anthropic SDK) هست؛ فعلاً برای اینکه بدون نیاز به کلید API هم بشه کل جریان
|
||||
رو با Swagger تست کرد، یک پاسخ ساده و قطعی برمی‌گردونه.
|
||||
⚠️ افزوده شده: lessonId/chapterId/questionId در قراردادِ API به‌صورتِ
|
||||
رشته (CharField) پذیرفته می‌شن، اما وقتی به‌عنوانِ ارجاعِ سبکِ (لایه‌ی
|
||||
DB) روی Conversation/Message ذخیره می‌شن، فیلدِ مقصد IntegerFieldه.
|
||||
این تابع فقط تشخیص می‌ده که آیا مقدار برای ذخیره‌سازی در همچین
|
||||
فیلدی امن/عددی هست یا نه؛ روی مرزِ generate_tutor_answer اثری نداره
|
||||
(اونجا همیشه مقدارِ خامِ اصلی پاس داده می‌شه).
|
||||
"""
|
||||
if value in (None, ''):
|
||||
return False
|
||||
return str(value).strip().lstrip('-').isdigit()
|
||||
|
||||
|
||||
class AIProviderUnavailable(APIException):
|
||||
"""
|
||||
⚠️ افزوده شده: وقتی generate_tutor_answer به یک AI provider واقعی
|
||||
(OpenAI/GapGPT/...) وصل بشه، شکستِ فراخوانیِ شبکه‌ای (timeout، خطای
|
||||
provider و غیره) باید یک خطای واضح و قابلِ retry برای کلاینت باشه، نه
|
||||
یک 500 خام. جزئیاتِ فنیِ خطای اصلی در لاگ سرور ثبت می‌شه (نگاه کنید به
|
||||
AskAIView.post)، نه در پاسخِ کلاینت.
|
||||
"""
|
||||
|
||||
status_code = 503
|
||||
default_detail = 'سرویس هوش مصنوعی موقتاً در دسترس نیست. لطفاً دوباره تلاش کنید.'
|
||||
default_code = 'ai_provider_unavailable'
|
||||
|
||||
|
||||
def generate_tutor_answer(
|
||||
user_question: str, grade_id, lesson_id, context=None
|
||||
) -> tuple[str, list[str]]:
|
||||
"""
|
||||
مرزِ (boundary) تولیدِ پاسخِ AI Tutor — محلِ اتصال به مدل واقعی (مثلاً
|
||||
Claude API از طریق Anthropic SDK) در آینده.
|
||||
|
||||
🏗️ اصلاحِ معماریِ این دور: gradeId/lessonId که در تسکِ قبلی از این
|
||||
امضا حذف شده بودن، برگشتن — چون اینا metadata ای هستن که لایه‌ی RAG
|
||||
(که جداگانه و در آینده با Qdrant پیاده می‌شه) برای retrieveکردنِ حدوداً
|
||||
۵ chunk مرتبط از knowledge base واقعاً بهشون نیاز داره (کنارِ خودِ سوال).
|
||||
یعنی امضای این تابع الان: (user_question, grade_id, lesson_id, context).
|
||||
|
||||
- grade_id و lesson_id: مستقیماً از همون فیلدهای gradeId/lessonId که در
|
||||
بدنه‌ی درخواستِ POST /api/ai/ask می‌آن (v.get('gradeId')،
|
||||
v.get('lessonId')) به این تابع پاس داده می‌شن؛ قراردادِ API endpoint
|
||||
دست‌نخورده باقی می‌مونه.
|
||||
- context: یک پارامترِ عمومیِ اختیاریِ application-generated (رشته/شیء/
|
||||
لیستِ پیام — فرمتش تصمیمِ لایه‌ی RAG در آینده‌ست) که *این* تابع صرفاً
|
||||
مصرف می‌کنه، بدونِ اینکه بدونه از کجا اومده (retrieval از Qdrant؟
|
||||
چیزِ دیگه؟). یعنی جریانِ آینده:
|
||||
|
||||
gradeId + lessonId + userQuestion → لایه‌ی RAG (Qdrant) →
|
||||
~۵ chunkِ انتخاب‌شده به‌عنوانِ context → این تابع (لایه‌ی تولید) →
|
||||
provider
|
||||
|
||||
این تابع (و provider واقعی‌ای که جایگزینِ استابِ زیر می‌شه) نباید خودش
|
||||
Conversation/Message رو از دیتابیس بخونه یا تاریخچه‌ی خامِ مکالمه نگه
|
||||
داره — مالکیتِ تاریخچه‌ی مکالمه همیشه دستِ دیتابیسِ خودمونه، نه لایه‌ی
|
||||
provider؛ grade_id/lesson_id صرفاً metadataی retrieval هستن، نه
|
||||
تاریخچه.
|
||||
|
||||
در همین تسک، AskAIView هنوز context ای نمی‌سازه (لایه‌ی RAG/Qdrant
|
||||
جداگانه و بعداً پیاده می‌شه) و همیشه context=None می‌فرسته؛ پس رفتارِ
|
||||
فعلی (پاسخِ استابِ قطعی) بدونِ تغییر باقی می‌مونه — این فقط مرز رو برای
|
||||
آینده آماده می‌کنه.
|
||||
"""
|
||||
context_note = f' (با context: {context})' if context else ''
|
||||
answer = (
|
||||
f'این یک پاسخ نمونه (stub) برای سوال «{user_question}» است. '
|
||||
f'این یک پاسخ نمونه (stub) برای سوال «{user_question}»{context_note} است. '
|
||||
'برای اتصال به مدل واقعی هوش مصنوعی، این تابع را در ai_tutor/views.py '
|
||||
'جایگزین کنید (مثلاً با فراخوانی Anthropic API).'
|
||||
)
|
||||
@@ -41,12 +106,6 @@ class AskAIView(APIView):
|
||||
|
||||
permission_classes = [IsAuthenticated]
|
||||
|
||||
# ⚠️ افزوده شده: هدرِ اختیاریِ Idempotency-Key (دقیقاً همون الگویی که
|
||||
# payment و content/QuestionAnswerView و content/LessonCompleteView
|
||||
# دارن) که قبلاً برای این endpoint نه مستند بود و نه پیاده‌سازی شده
|
||||
# بود؛ نبودش یعنی رتری/دابل‌کلیکِ همون سوال می‌تونست یک پیامِ کاربر و
|
||||
# یک پیامِ دستیارِ تکراری بسازه و یک اسلاتِ کوتای روزانه‌ی اضافه مصرف
|
||||
# کنه.
|
||||
@extend_schema(
|
||||
request=AskRequestSerializer,
|
||||
responses=AskResponseSerializer,
|
||||
@@ -70,12 +129,7 @@ class AskAIView(APIView):
|
||||
user = request.user
|
||||
idempotency_key = request.headers.get('Idempotency-Key') or None
|
||||
|
||||
# ⚛️🔒 اصلاح idempotency: اگه کلاینت کلید idempotency فرستاده و
|
||||
# قبلاً همین درخواست با همین کلید کامل پردازش شده (AskIdempotency
|
||||
# موجوده)، به‌جای ساختِ دوباره‌ی پیام‌ها و مصرفِ دوباره‌ی کوتا، نتیجه‌ی
|
||||
# همون درخواستِ قبلی برگردونده می‌شه. کوتای «باقی‌مونده» دوباره از
|
||||
# روی وضعیتِ فعلی محاسبه می‌شه (نه مقدارِ زمانِ اولین درخواست) چون
|
||||
# این فراخوانی به‌خودی‌خود چیزی مصرف نکرده.
|
||||
# درخواست تکراری با همین کلید: نتیجه‌ی قبلی برگردانده می‌شود، بدون مصرف دوباره‌ی کوتا.
|
||||
if idempotency_key:
|
||||
existing = AskIdempotency.objects.filter(
|
||||
user_id=user.id, idempotency_key=idempotency_key,
|
||||
@@ -83,75 +137,64 @@ class AskAIView(APIView):
|
||||
if existing is not None:
|
||||
return Response(self._build_ask_response(existing).data)
|
||||
|
||||
# ⚠️ اصلاح: چک و مصرفِ کوتای روزانه قبلاً race condition داشت —
|
||||
# دو درخواست هم‌زمان از همون کاربر می‌تونستن هر دو شمارشِ «امروز»
|
||||
# رو قبل از ساختن پیامِ خودشون بخونن و هر دو رد بشن، در نتیجه از
|
||||
# سقف ۱۵ سوال روزانه عبور کنن. حالا با قفل‌کردن ردیف کاربر
|
||||
# (select_for_update) در یک تراکنش اتمیک، چک و مصرفِ کوتا برای هر
|
||||
# کاربر serialize می‌شه؛ درخواست‌های هم‌زمانِ همون کاربر منتظر آزاد
|
||||
# شدن قفل می‌مونن و دیگه نمی‌تونن هم‌زمان از کنار چک رد بشن.
|
||||
#
|
||||
# ⚛️ اصلاح اتمیک‌بودن: قبلاً ساختِ پیامِ کاربر داخلِ این atomic
|
||||
# commit می‌شد و بعد از بسته‌شدنِ تراکنش، generate_tutor_answer و
|
||||
# ساختِ پیامِ دستیار جدا (بدون atomic) انجام می‌شد. یعنی اگه بین
|
||||
# این دو مرحله خطایی پیش می‌اومد (مثلاً خطای شبکه‌ای هنگام فراخوانیِ
|
||||
# واقعیِ سرویسِ AI، یا خطای DB روی ساختِ پیامِ دستیار)، پیامِ کاربر
|
||||
# و مصرفِ کوتای روزانه‌اش برای همیشه در دیتابیس ثبت‌شده باقی
|
||||
# می‌موند، بدون اینکه هیچ پاسخی برایش ساخته شده باشد و بدون اینکه
|
||||
# کلاینت پاسخ موفقی گرفته باشد — یک «سوال یتیم» که هم کوتا را
|
||||
# مصرف کرده هم درخواست را از دید کاربر ناموفق نشان می‌دهد. حالا
|
||||
# ساختِ پیامِ کاربر، فراخوانیِ generate_tutor_answer و ساختِ پیامِ
|
||||
# دستیار همگی داخل یک تراکنشِ اتمیکِ واحدند: یا هر دو پیام با هم
|
||||
# commit می‌شن، یا (در صورتِ خطا) هیچ‌کدام، و کوتای روزانه هم در
|
||||
# آن صورت مصرف‌نشده باقی می‌ماند.
|
||||
# نکته برای آینده: وقتی generate_tutor_answer به یک فراخوانیِ
|
||||
# شبکه‌ایِ واقعی (مثلاً Anthropic API) وصل شد، اگر آن فراخوانی
|
||||
# کند/کندپاسخ باشد، بهتر است پیش از بازکردنِ این تراکنش (یا با
|
||||
# گرفتنِ پاسخ بیرون از قفلِ ردیفِ کاربر) انجام شود تا قفل برای مدتِ
|
||||
# طولانی نگه داشته نشود؛ این یک ملاحظه‌ی کارایی/همزمانی است، نه
|
||||
# صحتِ تراکنش، و در همین دور تغییر داده نشده.
|
||||
# ⚛️🔒 دفاع در عمق برای idempotency: اگه دو submit هم‌زمان دقیقاً با
|
||||
# همون Idempotency-Key وارد بشن (رتریِ واقعیِ شبکه‌ایِ کلاینت، درست
|
||||
# بعد از چکِ existing بالا و قبل از commit شدنش)، UniqueConstraintِ
|
||||
# سطح DB (uniq_ask_idempotency_key) جلوی ساختِ رکوردِ دومِ
|
||||
# AskIdempotency رو می‌گیره و کلِ این atomic block (شاملِ دو پیام و
|
||||
# مصرفِ کوتا) rollback می‌شه — دقیقاً همون الگویی که
|
||||
# QuestionAnswerView/LessonCompleteView در content و
|
||||
# apply_order_payment_result در payment دارن. در این حالت، به‌جای
|
||||
# خطا، نتیجه‌ی همون درخواستی که رقیب ثبت کرده رو idempotent
|
||||
# برمی‌گردونیم.
|
||||
# سه فاز جدا: فاز ۱ کوتای روزانه را زیر قفل ردیف کاربر چک/رزرو می‌کند،
|
||||
# فاز ۲ (فراخوانی AI) کاملاً بیرون از هر قفل/تراکنشی اجرا می‌شود تا
|
||||
# تأخیر شبکه قفل کاربر را نگه ندارد، فاز ۳ پیام دستیار و idempotency
|
||||
# را ثبت می‌کند. اگر فاز ۲/۳ شکست بخورد، رزرو فاز ۱ آزاد می‌شود.
|
||||
with transaction.atomic():
|
||||
AccountUser.objects.select_for_update().get(pk=user.id)
|
||||
|
||||
today = timezone.localdate()
|
||||
used_today = Message.objects.filter(
|
||||
conversation__user_id=user.id, role='user', created_at__date=today
|
||||
).count()
|
||||
if used_today >= DAILY_AI_QUOTA:
|
||||
raise Throttled(detail='سقف روزانه‌ی سوال از هوش مصنوعی به پایان رسیده است.')
|
||||
|
||||
conversation_id = v.get('conversationId')
|
||||
conversation_is_new = not conversation_id
|
||||
if conversation_id:
|
||||
# ورودی غیرعددی هم باید 404 بدهد، نه خطای خام ORM.
|
||||
try:
|
||||
conversation = get_object_or_404(Conversation, pk=conversation_id, user_id=user.id)
|
||||
except (ValueError, TypeError):
|
||||
raise Http404
|
||||
else:
|
||||
# lessonId/chapterId روی Conversation فیلدهای IntegerField هستند؛
|
||||
# مقدار غیرعددی نادیده گرفته می‌شود (None ذخیره می‌شود) اما مقدار
|
||||
# خام همچنان بدون تغییر به generate_tutor_answer می‌رسد.
|
||||
raw_lesson_id = v.get('lessonId')
|
||||
raw_chapter_id = v.get('chapterId')
|
||||
conversation = Conversation.objects.create(
|
||||
user_id=user.id,
|
||||
lesson_id=raw_lesson_id if _is_db_ref_id(raw_lesson_id) else None,
|
||||
chapter_id=raw_chapter_id if _is_db_ref_id(raw_chapter_id) else None,
|
||||
grade_id=v.get('gradeId'),
|
||||
)
|
||||
|
||||
raw_question_id = v.get('questionId')
|
||||
user_message = Message.objects.create(
|
||||
conversation=conversation,
|
||||
role='user',
|
||||
text=v['userQuestion'],
|
||||
question_id=raw_question_id if _is_db_ref_id(raw_question_id) else None,
|
||||
)
|
||||
# قفل ردیف کاربر اینجا آزاد شده؛ فراخوانی AI بیرون از هر تراکنشی اجرا می‌شود.
|
||||
# context برای لایه‌ی RAG/Qdrant آینده در نظر گرفته شده؛ فعلاً None است.
|
||||
grade_id = v.get('gradeId')
|
||||
lesson_id = v.get('lessonId')
|
||||
context = None
|
||||
try:
|
||||
answer_text, follow_ups = generate_tutor_answer(
|
||||
v['userQuestion'], grade_id, lesson_id, context
|
||||
)
|
||||
except Exception:
|
||||
logger.exception('generate_tutor_answer failed for user_id=%s', user.id)
|
||||
self._release_reserved_slot(conversation, user_message, conversation_is_new)
|
||||
raise AIProviderUnavailable()
|
||||
|
||||
try:
|
||||
with transaction.atomic():
|
||||
AccountUser.objects.select_for_update().get(pk=user.id)
|
||||
|
||||
today = timezone.localdate()
|
||||
used_today = Message.objects.filter(
|
||||
conversation__user_id=user.id, role='user', created_at__date=today
|
||||
).count()
|
||||
if used_today >= DAILY_AI_QUOTA:
|
||||
raise Throttled(detail='سقف روزانه‌ی سوال از هوش مصنوعی به پایان رسیده است.')
|
||||
|
||||
conversation_id = v.get('conversationId')
|
||||
if conversation_id:
|
||||
conversation = get_object_or_404(Conversation, pk=conversation_id, user_id=user.id)
|
||||
else:
|
||||
conversation = Conversation.objects.create(
|
||||
user_id=user.id,
|
||||
lesson_id=v.get('lessonId') or None,
|
||||
chapter_id=v.get('chapterId') or None,
|
||||
grade_id=v.get('gradeId'),
|
||||
)
|
||||
|
||||
user_message = Message.objects.create(
|
||||
conversation=conversation,
|
||||
role='user',
|
||||
text=v['userQuestion'],
|
||||
question_id=v.get('questionId') or None,
|
||||
)
|
||||
|
||||
answer_text, follow_ups = generate_tutor_answer(
|
||||
v['userQuestion'], v.get('gradeId'), v.get('lessonId')
|
||||
)
|
||||
assistant_message = Message.objects.create(
|
||||
conversation=conversation,
|
||||
role='assistant',
|
||||
@@ -166,6 +209,7 @@ class AskAIView(APIView):
|
||||
conversation=conversation,
|
||||
user_message=user_message,
|
||||
assistant_message=assistant_message,
|
||||
suggested_follow_ups=follow_ups,
|
||||
)
|
||||
except IntegrityError:
|
||||
if not idempotency_key:
|
||||
@@ -175,9 +219,10 @@ class AskAIView(APIView):
|
||||
).select_related('conversation', 'user_message', 'assistant_message').first()
|
||||
if existing is None:
|
||||
raise
|
||||
self._release_reserved_slot(conversation, user_message, conversation_is_new)
|
||||
return Response(self._build_ask_response(existing).data)
|
||||
|
||||
used_today += 1 # همین سوالی که الان ثبت شد هم جزو مصرف امروزه
|
||||
used_today += 1 # سوال همین درخواست هم جزو مصرف امروز است
|
||||
remaining_quota = max(DAILY_AI_QUOTA - used_today, 0)
|
||||
|
||||
data = {
|
||||
@@ -189,21 +234,35 @@ class AskAIView(APIView):
|
||||
}
|
||||
return Response(AskResponseSerializer(data).data)
|
||||
|
||||
def _release_reserved_slot(self, conversation, user_message, conversation_is_new):
|
||||
"""پاک‌کردن رزرو فاز ۱ وقتی فاز بعدی شکست می‌خورد، تا نه پیام یتیم بماند و نه کوتا مصرف‌شده حساب شود."""
|
||||
with transaction.atomic():
|
||||
if conversation_is_new:
|
||||
conversation.delete()
|
||||
else:
|
||||
user_message.delete()
|
||||
|
||||
def _build_ask_response(self, existing: AskIdempotency) -> AskResponseSerializer:
|
||||
"""
|
||||
ساختِ همون پاسخِ AskResponseSerializer برای یک AskIdempotency
|
||||
از قبل ثبت‌شده (مسیرِ idempotent replay)، بدونِ ساختِ پیامِ جدید یا
|
||||
مصرفِ کوتا. suggestedFollowUps ذخیره نشده (فقط متنِ پاسخِ نهایی در
|
||||
Message.text ذخیره‌ست)، پس با فراخوانیِ دوباره‌ی همون تابعِ خالص و
|
||||
بدونِ اثرِ جانبیِ generate_tutor_answer (نه ساختِ پیام، نه مصرفِ
|
||||
کوتا) روی همون سوالِ ثبت‌شده بازسازی می‌شه؛ remainingQuota هم از
|
||||
روی مصرفِ *فعلیِ* امروز محاسبه می‌شه، نه لحظه‌ی درخواستِ اولیه، چون
|
||||
این فراخوانیِ idempotent به‌خودی‌خود چیزی مصرف نکرده.
|
||||
مصرفِ کوتا.
|
||||
|
||||
⚠️ اصلاح: قبلاً suggestedFollowUps ذخیره نمی‌شد و اینجا با
|
||||
فراخوانیِ دوباره‌ی generate_tutor_answer بازسازی می‌شد. تا وقتی
|
||||
generate_tutor_answer یک stub خالی از اثر جانبیه بی‌ضرر بود، اما
|
||||
وقتی به یک AI provider واقعی وصل بشه، هر replay یک فراخوانیِ
|
||||
واقعیِ دیگه به provider می‌زد (هزینه/تأخیرِ تکراری، و
|
||||
suggestedFollowUps متفاوت در هر retry — دقیقاً برخلافِ هدفِ
|
||||
idempotency). حالا suggested_follow_ups مستقیماً از خودِ رکوردِ
|
||||
AskIdempotency (ذخیره‌شده در همون درخواستِ اولِ موفق) خونده می‌شه؛
|
||||
هیچ فراخوانیِ دیگری به generate_tutor_answer در مسیرِ replay انجام
|
||||
نمی‌شه. answer هم مثلِ قبل از Message.text (بدونِ تغییر) خونده
|
||||
می‌شه؛ remainingQuota هم مثلِ قبل از روی مصرفِ *فعلیِ* امروز
|
||||
محاسبه می‌شه، نه لحظه‌ی درخواستِ اولیه، چون این فراخوانیِ
|
||||
idempotent به‌خودی‌خود چیزی مصرف نکرده.
|
||||
"""
|
||||
conversation = existing.conversation
|
||||
_, follow_ups = generate_tutor_answer(
|
||||
existing.user_message.text, conversation.grade_id, conversation.lesson_id
|
||||
)
|
||||
today = timezone.localdate()
|
||||
used_today = Message.objects.filter(
|
||||
conversation__user_id=existing.user_id, role='user', created_at__date=today
|
||||
@@ -214,7 +273,7 @@ class AskAIView(APIView):
|
||||
'conversationId': str(conversation.id),
|
||||
'messageId': str(existing.assistant_message.id),
|
||||
'answer': existing.assistant_message.text,
|
||||
'suggestedFollowUps': follow_ups,
|
||||
'suggestedFollowUps': existing.suggested_follow_ups,
|
||||
'remainingQuota': remaining_quota,
|
||||
}
|
||||
return AskResponseSerializer(data)
|
||||
|
||||
Reference in New Issue
Block a user