Skip to content

Commit 720d9cc

Browse files
committed
Add new Logseq person reference and journal entries for April 2025
- Introduce a new Logseq-Flavored Markdown (LFM) person reference file to guide users on how to track and document person entries in Logseq. - Create journal entries for April 14 and 15, 2025, detailing various topics including FastAPI background tasks and conference notes. - Add new pages on Layer 1 protocols in cryptocurrency and enhance existing documentation for FastAPI background tasks, improving clarity and organization.
1 parent 04276da commit 720d9cc

24 files changed

Lines changed: 1068 additions & 6 deletions

.cursor/rules/logseq-person.mdc

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
---
2+
description: Logseq-Flavored Markdown (LFM) Person Reference
3+
globs:
4+
alwaysApply: false
5+
---
6+
# How a Person is tracked in this Logseq knowledge garden
7+
This is an extension to [logseq-flavored-markdown](mdc:.cursor/rules/logseq-flavored-markdown.mdc) for recording information about a person.
8+
9+
A person entry is a logseq page where [[Person/Full Name]] corresponds to `pages/Person___Full Name.md`.
10+
11+
If you are asked to make an entry for a person, you should do a search
12+
* search in `pages/Person___*.md` to find if a person already exists
13+
* if it already exists, then you should **update** the existing entry
14+
* a single person should not have more than one person page
15+
* look up the person on the internet
16+
* create a person page for them
17+
* link the person and a bit of their bio in their page
18+
* if possible add an image link
19+
* if the person page is new, make an entry in today's journal page that links to that person.

journals/2025_04_14.md

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
## [[Py/asyncio]]
2+
- [[FastAPI/BackgroundTasks/Q/Is it possible to enqueue a task inside a task]]
3+
- [[FastAPI/Docs/Tutorial/Async]]
4+
- [[FastAPI/BackgroundTasks/Q/When should I use run_in_threadpool]]
5+
- ## Jira weirdness
6+
- [[JIRA/How To/Filter for tasks assigned to a particular user after they become inactive]]
7+
- ## [[AI/Conference]]
8+
- [[MIT/Conference/IIA/25/04/15]]

journals/2025_04_15.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
- [[MIT/Conference/IIA/25/04/15]]
2+
- [[MIT/Conference/IIA/25/04/15/Shortlist]]

pages/Crypto___Layer 1 Protocol.md

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
- A **Layer 1 protocol** refers to the **base-level blockchain architecture** — the foundational layer upon which everything else is built. It handles core functions like:
2+
- **Consensus** (how nodes agree on the state of the network)
3+
- **Data availability** (who stores what)
4+
- **Transaction execution** (who does the computation)
5+
6+
Examples:
7+
- **Ethereum**
8+
- **Bitcoin**
9+
- **Solana**
10+
- **Avalanche**
11+
12+
When people say “Layer 1,” they mean the **primary chain** itself — not the apps on top, and not scaling solutions. By contrast:
13+
- **Layer 2 protocols** (like Optimism or Arbitrum) are **built on top** of Layer 1s to improve speed, reduce cost, etc.
14+
- **Apps/dapps** run above Layer 1 and Layer 2.
15+
16+
In the agent context, if someone says “we’re building a Layer 1 for agents,” they probably mean:
17+
18+
> “We’re creating a foundational decentralized protocol where agent communication, coordination, and transactions happen natively — not as an app on Ethereum, but as its own network.”

pages/Data___Gravity.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
alias:: [[Data Gravity]]

pages/FastAPI___BackgroundTasks.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
alias:: [[FastAPI Background Task]], [[FastAPI Background Tasks]]
Lines changed: 134 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,134 @@
1+
tags:: [[FastAPI]], [[Q]], [[BackgroundTasks]]
2+
3+
- # Is it possible to enqueue a [[FastAPI Background Task]] from inside another task?
4+
- ## Summary
5+
- When using FastAPI's background tasks, we sometimes need to trigger additional background tasks from within an already running background task
6+
- For example:
7+
- A request comes in to process an order
8+
- We start a background task to check the order status
9+
- While checking the status, we discover we need to send a notification
10+
- At this point, we want to enqueue a new background task for sending the notification
11+
- The challenge is that background tasks in FastAPI are tied to the HTTP request lifecycle:
12+
- The `BackgroundTasks` object is created when the request starts
13+
- Tasks are added to this object before sending the response
14+
- The tasks run after the response is sent
15+
- Once the response is sent, we can't add new tasks
16+
- This creates a limitation where nested or chained background tasks are not directly supported
17+
- ## Example
18+
- ```python
19+
def process_order(order_id: str, background_tasks: BackgroundTasks):
20+
# Process the order
21+
order = process_order_details(order_id)
22+
23+
# Send initial confirmation
24+
background_tasks.add_task(send_confirmation_email, order.email)
25+
26+
return {"message": "Order processing started"}
27+
28+
async def check_order_status(order_details):
29+
print("Checking order status...")
30+
31+
# Simulate checking order status
32+
if order_details.get("status") == "pending":
33+
try:
34+
# Get order from database
35+
order = get_order_by_id(order_details["order_id"])
36+
37+
if not order:
38+
print("Order not found")
39+
return None
40+
41+
# Here's where we want to enqueue another background task
42+
# But we don't have access to the original background_tasks object
43+
# send_status_update(order.email, "Order is being processed")
44+
45+
except Exception as e:
46+
print(f"Error checking order status: {e}")
47+
return None
48+
49+
print("Status check complete")
50+
return None
51+
52+
def send_status_notification(
53+
order_id: str,
54+
background_tasks: BackgroundTasks,
55+
):
56+
# Get order details
57+
order_details = {"order_id": order_id, "status": "pending"}
58+
59+
# Add background task to check status
60+
background_tasks.add_task(check_order_status, order_details)
61+
62+
return {"message": "Status check scheduled"}
63+
```
64+
- ## Research
65+
- According to FastAPI documentation:
66+
- Background tasks are run after returning the response
67+
- `BackgroundTasks` can be injected as a parameter at multiple levels
68+
- Tasks can be either async or regular functions
69+
- Background tasks are meant for lightweight operations
70+
- For heavier tasks, FastAPI recommends using tools like Celery
71+
- Key limitations:
72+
- Background tasks are tied to the request lifecycle
73+
- Once a response is sent, you can't add new tasks to that request's background tasks
74+
- Tasks run in the same process as FastAPI
75+
- ## Analysis
76+
- The challenge in the example code:
77+
- The `check_order_status` function is run as a background task
78+
- Inside it, we want to send a status update email
79+
- But we don't have access to the original `background_tasks` object
80+
- Even if we did, the response would already be sent by then
81+
- Potential solutions:
82+
- 1. Pass the `background_tasks` object through to the inner function
83+
- 2. Use a proper task queue system like Celery
84+
- 3. Handle all potential notifications in the initial task
85+
- 4. Use event-driven architecture with a message broker
86+
- ## Answer
87+
- No, it is not possible to enqueue a new FastAPI background task from inside another background task after the response has been sent
88+
- This is because:
89+
- Background tasks are tied to the HTTP request lifecycle
90+
- They are executed after the response is sent
91+
- Once the response is sent, you can't add new tasks
92+
- Recommended solutions:
93+
- For simple cases:
94+
- Plan all potential background tasks upfront
95+
- Add them all to the `background_tasks` object before returning the response
96+
- For complex cases:
97+
- Use a proper task queue system like Celery
98+
- This allows tasks to spawn other tasks
99+
- Provides better handling of long-running operations
100+
- Supports task scheduling and retries
101+
- Example of the recommended approach for simple cases:
102+
- ```python
103+
def process_order(order_id: str, background_tasks: BackgroundTasks):
104+
# Add all potential background tasks upfront
105+
background_tasks.add_task(send_confirmation_email, order.email)
106+
background_tasks.add_task(check_order_status, order_id)
107+
background_tasks.add_task(send_status_update, order.email)
108+
109+
return {"message": "Order processing started"}
110+
```
111+
- For more complex workflows:
112+
- ```python
113+
from celery import Celery
114+
115+
app = Celery('tasks', broker='redis://localhost:6379/0')
116+
117+
@app.task
118+
def process_order(order_id: str):
119+
# Process order
120+
order = process_order_details(order_id)
121+
122+
# This task can spawn other tasks
123+
check_order_status.delay(order_id)
124+
return {"message": "Order processing started"}
125+
126+
@app.task
127+
def check_order_status(order_id: str):
128+
# Check status
129+
status = get_order_status(order_id)
130+
131+
# Can spawn new tasks as needed
132+
if status == "processing":
133+
send_status_update.delay(order_id, status)
134+
```
Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
# When should I use [[FastAPI/currency/run_in_threadpool]]?
2+
-
Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
# [Concurrency and async / await - FastAPI](https://fastapi.tiangolo.com/async/)
2+
- ### async and await
3+
- > I created another library on top of AnyIO, as a thin layer on top, to improve a bit the type annotations and get better **autocompletion**, **inline errors**, etc. It also has a friendly introduction and tutorial to help you **understand** and write **your own async code**:  [[Asyncer]] [Asyncer](https://asyncer.tiangolo.com/). It would be particularly useful if you need to **combine async code with regular** (blocking/synchronous) code.
4+
- ### [[FastAPI/Docs/Tutorial/Async/Very Technical Details]] [here](https://fastapi.tiangolo.com/async/#very-technical-details)
5+
- > When you declare a *path operation function* with normal `def` instead of `async def`, it is run in an external threadpool that is then awaited, instead of being called directly (as it would block the server).
6+
-
Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
# How to filter for tasks assigned to a particular user after they become inactive in [[JIRA]]
2+
- 1 - find the user's profile
3+
- try to find a ticket that was assigned to the user
4+
- then click through to that user's profile
5+
- the profile will like `https://<YOURDOMAIN>.atlassian.net/jira/people/<ABOUT_SIX_NUMERIC_DIGITS>:<UUID_HERE>`
6+
- here the username is now `<ABOUT_SIX_NUMERIC_DIGITS>:<UUID_HERE>` for the purposes of filtering
7+
- for example, the [[JIRA/JQL]] to filter for the tickets assigned to this particular user would be
8+
- ```jql
9+
assignee = <ABOUT_SIX_NUMERIC_DIGITS>:<UUID_HERE> order by created DESC
10+
```
11+
-
12+
-

0 commit comments

Comments
 (0)